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PREFACE 



This book is written for systems designers and operating system designers and programmers who plan, 
to use the Intel iAPX 286 microprocessor in its protected, virtual-address mode. The protected-mode 
iAPX 286 is designed fcM* inulti^$l(^|g^^n^.^^^(^,t|bat ^p^^ in|p^users or^that s^elt^^^ly^ 
run several programs. ^ a • ' 

This bodk' an^yzes operating system functions that are appropriate for the iAPX 286 when used in a ' 
variety 'Of multitasking applications, including ,. 

_ . . . ■■' \f "^i*. -ii'.vi ..v.ixVV yj- Tr,'.. . J >*nt.<it. .ni.Etaw*l • 

• Communications, such as automated PBXs ^ ii. f., 

• Real-time, such as instrumentation or process control 

• Multi-user, such as time-sharing or office systems 

Many of the features of the iAPX 286 are intended for use by an operating system. This book identifies 
and explains those features and gives examples of how they can be used in an operating system. 

MfV- . > . ?r.jii!ijiaiimfaoo .•-..nii-irm ^ribuir./n .«noiia-ji!c[r,ij !o .■, ■ ; >rji* b lol 

AUDIENCE 

This book assumes that you have a knowledge of multitasking operating systems at least equivalent to 
that presented in introductory undergraduate textbooks on the subject. It also assumes that you have 
had some exposure to the architecture of the iAPX 286 through attending an introductory course or. 
reading introductory literature sue! as MiroductioH to the iAPX 286. 

, . . 1 • 

!ioi:;-i:.a<nfi3n rftiw ^rro' ; ■ "Lr'^ • 

RELATED PUBLICATIONS ' ' < s i r ; i 

Intel Literature 

The follWOTg taanuals conti&^^Sliitidijfal: iirfdrtiatioh 6f isfe te bpei^ 

• di'.i.'A 8«ii«fu .erjsnii; < ■■■ -ti.- /'.:rr.\ 

ASM 286 Assembly Language Reference^^^dt^, 121924 

Component Data Catalog, 21029S , , , 

ij^X2B6 Architecture Extension Kernel (K286) User's Guide, 121961 
iA^X 286 Programmer's ■Mt^^mtce Manual, 2 10498 
iAPX 286 System Builder Usa-'s Q^^ tit^ 

iAPX 286 Utilities User's Guide, \21934 «vi)j -; .' f.s , '5 irunffn «iiiT 

Introduetijm to the iAPX 286, 210308 
PL/M-286 User's Guide, \2\9A5 
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External Literature 



Many aspects of operating system construction for the iAPX 286 are the same as for other processors. 
The following are sources of generally applicable theories and algorithms referred to in the text of this 
book.' ■ ■ ■ '-v' i;:--"^-.' . . 

. Coffman, E.G., Jr., sinA -Mei' jC'B&xmi^''dpi^^ Cliffs, 
Prentice-Hall, 1973) 

», penning, Peter J., "Virtual Memory/' Computing Surveys, Vol. 2, No. 3 (September 1970) 

• Knuth, Donald E., Fundamental Algorithms, Vol. 1 (Rs^laiflgV'MtStlS- AMson-Wesley, 1973) ' 

• Peterson, James L., Petri Net Theory and the Modeling of&fsteim {Eaglewood Cliffs, N. J.: Prentice- 
Hall, 1981) ?/#rb9nn,M.r.^.. . 

RELATED PRODUCTS 

Designers interested in oper^tiflsg systems for the protected-mode iA(P)£r286 should also be aware pf 
Intel's iAPX 286 Architecture Extension Kernel K28. K286 is an operating-system kernel designed 
for a wide variety of applications, including real-time, communications, business systems, and time- 
sharing. K286 provides 

Short-term, priority scheduling and management of multiple tasks 

Interrupt management „ ,,, 
Multiprocessorsupport i I'^'.-'iJi^- >'.-.'. 1 -ai !f , j 
Virtual memory support 
Data sharing among tasks with synchronization 

Intertask signals and messages y:-^,, ; v. i ■ J2r 

Extended protection 

Whether you use K286 "as is," for greatest possible efficiency, or whether you add layers of software 
to more fully support your applications, K286 can significantly reduce your system development time. 
Since K286 has been designed by the architects of the iAPX 286 and implemented and tested ^X- 
Intel's software engineers, using K286 can make your system more reliable. 

^286 implements many of the concepts discussed in this book, which can therefore give you additional 
understanding of why and how to use K286. f*^''". .i. \. 

.•iuiV> /-i^.^.i lo^'i.Al u;v.vA ■- - ; 

HOW TO USE THIS MANUAL v^i O! ^ v ..u ^ ^ 

c '. 1 .iVlU j ?.'Vj/.'J A-V,,! 

This manual has two related objectives: 

• To identify features of the iAPX 286 architecture that are unique when appEed to the implemen- 
tation of an operating system 

• To show how you can effectively use these unique features m tne design of familiar operating system 
functions - • > » 
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PREFACE 



In pursuit of these objectives, Chaptej^ tliru 13 sha^ea gpperal, three-part structure: 

1. Identifing an operating system function (or class of functions). The functions ^^''^^SJ^sl^^S 
with which you might already be familiar, since they arc similar to those used in sitare^raftSS' 
operating systems such as iRMX 86 (from Intel Corporation) or UNIX (from Bell Laboratories). 

2. Reviewing the iAPX 286 features that support that function. While this portion of each chapter 
may cover some material available in other Intel literature, it ppS\«idi|si added value by discussing 
in one place !^ the iAPX 286 features that bear on a given qper^tiitg system function and by 
identifying relationships among those features. 

3. Outlining some examples of how to use those iAPX 286 features in an implementation of the 
identified function. It is, of course, impossible to illustrate all the ways to design any given function, 
but these examples serve to illustrate a few of the ways that the designers of the iAPX 286 archi- 

' lecture intended for it to be iUKdied. " 

.t.f- . - -■^■:>v? -MH,'.f>o? 

Chapter 1 introduces the iAPX 286 architecture; iitettSes the role of an operating system in a protected, 
multitasking environment; and shows how Intel's .^D^CU' and Builder utilities aid in the construction of 
an operating system. You may skip Chapter 1 if you.^e ak^^ f^upai^frf.mb H^titasldn|> qg(»atiag 
systems and with the Binder and the Builder. 

Both Chapter 2 and Chapter 5 contain key information about manipulating the protection features of 
tt^ iAPX 286. Be sure not to omit thesfedb^pMi«lien scan«ing<t&&«6&tMi!»f^ ' 

For the remaining chapters, you may turn directly to the subjects that interest you most. You will find 
the reading easier, however, if you observe the partial orderiai^ outMned in til^ 0-1 . 



NOTATIONAL CONVENTIONS 



UPPERCASE Characters shown in uppercase must be entered injy^^der shown. You may 

enter the ch*r«lMi^ ift upipercass or towftf case. 

HM^ Italic .iBiica^.a meta symbol that may be replac^A wtdr^a^iteffl'^d^ fuifUb 

the rules for that syml>B^,']^;|jf|,ual |y.mbQl may bje any of the following: 

^^tent-id Is a generic label placed on sample listinj^^ v^l^re, an ppefatjng 53rstem- 

' dependent name would actually be printed. 

Vx.y Is a generic label placed on sample listings where the version number of the 

( T product that p3iM^#ffi Bsting wtmld actuailjfibe pianttid. , > - 



Tablf 0-1, Prerequisites by Chapter 



r. Target Chapter 


Prerequisites 


Tr 

. 6 


A 


7 




8 


4, 6 


9 




■.' 12 


4, 6, 7 



'i'^: mb 
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CHAPTER 1 

• , INTRQPUCTION TO PROTECTED MULTITASKING 
r ' ON THE iAPX 286 

The iAPX 286 architecture views the software system (the operating system as well as applications) as 
a ttumber of asynchronous tasks, each task possibly consisting of levels of procedures deserving differ- 
ent degrees of "trust." An operating system for the iAPX 286 must (with the help of the hardware) 
coordinate the activities of multiple tasks and administer proteetion among tasks and among levels of 
tPP^i^eg iwithin Igsks, 

■ ' i ■; t : , 1 ■ ' ■ " 
I i-.i.v •: 

TASKS ■ -'■'•'^ ■■ ■ ■ • 

A task is the execution of a sequence of steps. A program is a logical entity that can have many 
representations: for example, source code file or object program file. A program becomes a task when 
it is actually available for execution. This is achieved by converting source (with a compiler and program 
loader, for example) to a representation suitable for execution and notifying the operating system that 
the task is ready for installation and execution. 

The distinction between programs and tasks is most clear in a multitasking system, where it is posstbli 
for two or more tasks to use one program simultaneously. The line editor program in a timesharing 
system is a common example. Even though each line editor task uses the same program, each task 
produces different results, sinc&it receives dil fe i w i it ^M j Mtti. ^ 




Structure of a Prq^ram'^^^ ^ 

Each program is formed from modules created by language translators and bound together into a single 
^executable unit. The translators (for example, ASM286, PL/M-286, Pascal-286, and FORTRAN-286) 
jand the object program utilities (for example, Intel's Builder and Binder) support the concept of logical 
iSegments. A logical segment a contiguous block of either instructions or data. Each logical segment 
ican contaia-a^ tc| 64K bytesH^ code or data. Logical segments are the units that may be combined 
jwhen a prtj^aW oomprises mbre than oiie-inodujfe^v 



Segmented Mesmory | /j^^l^^^^ 




MSJ-i. ... 
100.) 



The iAPX 286 structures the address space of a task into physical segments of variable length. A 
physical segment is a contiguous block of memory that does not (normally) overlap another physical 
segment. Each physical segment may contain up to 64K bytes of either instructions or data. Each 
physical segment contains one or more logical segments of a task. The segments reflect how tasks are 
organized into code, data, and.$tack areas. 1 



[Multitasking 

JOne of the most important features of the iAPX 2§i6 Is its ability to swMcl rapidly from executing on^ 
talk to executing, another task^This gives the appearance that the processor is executing, more thas 
one task at a tiiqe^ . -1 -! .ti , 
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Hardware system tables enable both the hardware and the jQperating system to distinguish between the 
physical segments of individual tasks. Figure 1-1 shows how fdqrsical segments of one task are logically 
separate from those of othef t^k^. Since references to physical segih^ts aUt always relative to system 
descriptor tables, the actual locations of physical segments in physical memory are not significant to 
the tasks and therefore are not illustrated. 



J^eserfptor tables serve not only t0~i<i0i0y itlie i^0i<en$s#«t' l»eli^4o^ a task but also to isolate Uta 
address space of one tas^-from that of another, so that one task cannot inadvertently affect the opera- 
tions of another. 



Multitasking works through close interaction of the operating system with hardware features. When 
the executing task needs to wait for some event (such as the arrival of data from some I/O device), it 
notiHes the operating system. The operating system determines which other task should execute next, 
and then causes the processor to store the state of the current task, retrieve the state of the next task, 
and begin executing the next task at the point where its processing last halted. The processor then 
executes that task until the task needs to wait for some event. (This is a somewhat oversimplified 



ij-.' 
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Figure 1-1. Segregation of Segments by Tasks with Private LDTs 
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description of what can be a complex operating system function. Chapter 4 covers the subject of task 
switching in more detail.) 

Fifore 1-2 illustrates how the global deseriptor table defines an address space that is accessible to .al| 
t^Pte the systeitft. ^Hm global spac^'^'i^M^for translation tables, tufl^tefflwaries, d^tifig- 
Sj^ih code and data, arid the like. ' / ■ . , j (.iqmB/^s ' ' • 



PRIVILEGE LEVELS < n 

1I&eJAPX '386-at<jKhecture uses the concept of privilege levels to protect critical procedures within a 
tSik trota less trusied procedufK Hi'&e>^«affiie task. For example, with previous generations of micro- 
processors, applications code OOflid^SRS^SS'iljnd possibly destroy tables Used by the operating system. 
An error of this sort could cause the operating system to incorrectly service a subsequent request from 
another unrelated task. With the iAPX 286, such situations are prevented by hardware-enforced barriers 
between different levels of proceitifes.' i ' • m ^'l. ■ , .^< r.!..!:,/„ ; , . 



GLOBAL SiMkQI 




LOCAL SNkS^ 
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' Figure 1-2. Global Segments In System 
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4^^1i0d;to procedures, privilege; l^el is a ineasu^;@fit|i? degree to which you trust a procedure nrt to 
make a mistake that might affect other procedures or data. Applied to data, privilege level is a measttre 
of the protection you think a data structure should have from less trusted procedures. 

Privilege level also applies to instructions. Certain instructions (those that deal with system tables, 
interrupts, and I/O, for example) have such an effect on the system as a whole that only highly trusted 
procedures should have the right to use them. 



Levels of Segments ' 

With regard to privilege, you can view the segments of a task as being grouped into four levels. Level 
zero is for the most privileged procedures and the most private data; level three is for the least trusted 
procedures and the most public data. You (or your operating system) associate each segment of each 
t»sk with one of these four kyels of wikge, Xl^, privilege level ctf a sefUjeRt applies to all the ptm&- 
ivtm muM tbe data in thatist@ismt<r)I^ferltliAstiates tfie ItDgicatssegregatmiof ^pnentsfiato 
privilege levels. (Later chapters explain why operating-system segments 'tn^ included within thc^ask;) 
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Figure 1-3. Segment Segregation by Privilege Level within a Task 
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(Rules of Privilege 

The 80286 processor controls access to both iai* fmxdnm between levels of a task. These rulqs 

define access rights: 

i 

• Data can be accessed only from^thrlaine or a more privileged level. 

' • A procedure can be called <Jf^ fiom the same level (bt from a less privileged level, if the service h 
} deliberately "exported'Uo that levei^fiefS'log^^^ \^ 

i ""^^ \ 1 

. ■ \ I 

ISOFTWARE SYSTEM STRUCTURE 

The way you choose to distribute software and data among tasks and privilege levels affects the relia^ 
bility, efficiency, and flexibility of your system. Operating-system modules may be segregated intii 
itheir own ta^ or may be distributed among and shared by every task. Some ^vantages of placing ; 
operating-system modules in separate tasks are 

• Finer granularity of protection is achieved by using task separation as well as privilege levels. 
'• Operating-system functions can execute in parallel with the caller. 

• When only one task at a time can perform the function (for example, reading from a keyboard), 
serializati(pn of rgflpests is automatic; yoi) do not need to synchronize ai iiiaB ^ - n qaestaj^ ts^ss. 



Some advanta|es-bf distributing operating-system functions are 



• The communication between ap^^i^^bn and operating system is faster 

• It may be possible for all tasks to execute the same operation-system fuh^tjcmiin parallel. (You mu^ 
ensure reentrancy and provide for synchronization, however.) j 

Figures 1-4 through 1-7 illustrate some general approaches that you may consider. 

The approach shown in figure l-4''Hl&gS maiiiawn advantage of the four privilege levels. The critic^ 
procedures and data of the operatic ^{£m!>leernel 4for exafi{pIe, memory allocation tables and procel- 
dures, information about tasks) are protected from all other procedures in the system. Those parts of 
the operating system that are less reliable, either due to inherent complexity (for example, the I/O 
subsystem) or due to occasional changes (for example, policies designed to increase overall through- 
put), are at a lower level but are still protected from application levels. Application logic has two levels 
so that application services (such as database management) can be protected from less trusted appli- 
cation code, yet application services cannot affect the integrity of the operating system. Operating- 
system procedures and appliealSdtfs^^j:feg ^%M tfl^lM f ^§% B%fe Wife' in the system. 

Figure 1-5 illustrates that you do not nc«d to use all four privilege levels. Yon may prefer this two-level 
iq^liroach if you are converting from a traditional multitasking system that offers protection only between 

the two levels defined by application and operating system. 

The iAPX 286 can also emulate one-level systems, as illustrated in figure 1-6. This approach may be 
useful in the initial stages of converting from an unprotected system, but it does not take advantage of 
many of the protection features offered by the iAPX 286. It does isolate tasks from one another, but 
it does not protect the operating system fram i 



Some operating system functions are better structured as independent operating-system tasks, not as 
^vileged procedures within a task. C^tain i/^fiuietiiHn %re /suited to ^m^emimat.Bsi!^am of the 
obiapteuty xtf I/O-jcode, the!extra. {»a^9itiitoaiiefli#lp»»Blr;h«ind^ 
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Figure Al:Qui;-Lev«i Protectipfi Structuro 



af the system. Because many I/O functions involve waiting for res|)onses from I/O devices, it is fflost 
convenient to treat these functions as a sepm^:tsii^'^^^lmflr^ii^te@iifftisly wi to tie 

tasks that invoke them. Figure 1-7 illustrates a structure vi^ith independent operating-system tasks. 

' »••••• 'I' ■.• ••-..tJi .cin-j.'-. ' . .-no i.'-.li • • . : 

ROLE OF THE OPERATING STStEM" ' - s v . i .r 



The role that an operating system may play in managing a multitasking execution environment depends 
the nature of the applicatiofli! AppfioatioHsi im k^ classified according to the volatility of iaisks 
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Figure 1-5. 



A Two-Lavel Wrt^tsH^m Wlm^^m 



executing over a period of time. Applications in which tasks frequently begin and end (for example, 
time-sharing systems or multi-user business systeM) ai» call^i dynamic systems. Applications in which 
the mix of tasks does not change (for example, pmsm emtsol systems in which tasks service a fixed 
number of sensors and effectors) are called static j^xlems. 



■J. I.: ,)■:■•,■ 

JfiSfT'.l,. 



Common O.S. Functions 

The operating-system roles common to both static and dynamic applications are 

• Allocation of the processor or processors to tasks 

• Coordination and communication among cooperating tasks 

• Processing of interrupts and exception conditions 'i j i«o< .ni,i^i>: 

• Standardization of interfaces to I/O devices ' T^-'* 

• Control of the numerics proce^or extension 



;:r ' i ' 
' f. ■ 
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Figure 1-6. A One-Level Unprotected Structure 



iP.S^ Functions in a Pynamic Environment 

Even though many of the duties of an operating system in a dynamic environment resemble those in a 
static environment, the dynamic environment often introduces new complexities. Some additional 
fpnt^ions that a dynamic s^tep nrn^ i)^ ., , ^ 

•, Real memory management 

• Program loading . <•■.' , •> .i'-.,/ , i ' 

• Command language interface 

• Virtual memory management -ire;" ' ' : ' ' .'"'L 

• Load-time binding 

. ji '.r. ri.!': , cvi) ^0(. ..;•(.., n..- : ■ . j ■ j. ' 

CONSTRUCTING THE INITIAL mJN-IIMillfl^l^aMMI^ 

Intel's System Builder program helps you create the initial executable system. The Builder program 
collects object modules into one module, assigns physical addresses, creates system tables, and assigns 
privilege levels. A specification language gives you the ability to control precisely what the Builder 
does. I 1 ' ;■ - 
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Figure 1-7. Independent Operatlng-Sys^tem Tasks 



Bui|dijig aJS.jatic^ System ^ j ^-,rT.;a , I 

In the case of static systems, the Builder does nearly all the work in constructing a running system. 
Refer to figure 1-8 for an illustration of the building process. The output of the Builder is a single 
module that contains all the tasks, both for the operating system and for applications, as well as all 
system tables and protection information. The Builder's output file has a format that simplifies creation 
of a bootstrap loader for the system. 



Building a Dynamic System 

With dynamic systems, the Builder constructs as much of the final system as you can specify in advance, 
but the nature of dynamic systems is such that the operating system must do at run-time many of the 
joperations that the Builder does for static systems (fer &m^^ ^^oeaMm Of m^pry and assignment 
■^physical addresses). The opera- ^ g g yBtam mnat uf d ate g ygt e ro tali ea -jM BN^ainistw the protectim 
mechanisms as the running envit«tnrltaOi^figea£'^'t)t<i->S .S-f ewDi^ 
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Figure 1-9 illustrates the process of constructiBg a dynamic sj^itsan. Tlie "Builder creates a loadable 
module containing those operating-system functions that permanently reside in the running operating 
system, and it also creates a file that contains information about linking to operating-system primitives. 
Either a static linker (such as Intel's Binder) or a dynamically linking loader can use this information 
to help dynamically loaded tasks use operating-8y9teBfi^.uactions. 
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Figure 1-8. Building a Static System 
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Figure 1-9. Building a Dynamic System 
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CHAPTER 2 
USING HARDWARE PROTECTION PEAftfl^S 

The architecture of the iAPX 286 enables you to organize^ftVare systems so that each task is protected 
from inadvertent or malicious damage by other tasks and so that privileged procedures are protected 
from lower-level procedures. You control the degree of protection in your system by the way you set 
up protection parameters through the Builder or through operating system procedures. The processor 
interprets the protection parameters and automatically performs ail the checking necessary to imple- 
ment protection. 



ADDRESSING MECHANISM 

The protection mechanism of the IAPX 286 is embedded in the addressing mechanism. For an intro- 
duction to the addressing mechanism, refer to figure 2-1, which shows those portions of the addressing 
mechanism that are not concerned with protection features. From the point of view of the applications 
programmer, an address is a pointer. A pointer consists of two parts: a selector and an offset. The 
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selector portion identifies a segment of thfe.a#tiiPj||il^i4S the offset addresses an item within the 
segment relative to the begimaing of ths segssf nt,:' . - .-.i j.j r , \ 

A selector identifies a segment by reference to a descriptor table. Each entry in a descriptor table is a 
descriptor. A selector contains an index that identifies a particular descriptor in a particular descriptor 
mbiOi^ilhe descriptor contaiw^tll«.f^«M 1^^$^ j^|^:p|tbe,$egment. 

Wil&tmii^iiats.&xiA descriptors coataia i»d4iti@nal infsenai^ ^t f elates to the protection features of 
the iAPX 286: . stii^r- 



DESCRIPTORS 

A reference from one segment to another is realized indirectly through a descriptor, which ccmt^ins 
information about the referenced segment. All descriptors reside in a descriptor table. Every s^Adent 
must have at least one descriptor, otherwise there is no means to address the segment. 

Descriptors are strictly under your control via the Builder or operating system procedureSi'TheJ^tisfc 
ence and function of descriptors is completely invisible to the applications programmer. ' ■ . 

Descriptor Format 

There are four variations in descriptor format, corresponding to the four classes of descriptor: 

1 . Data segment descriptors refer only to segments that contain system or application data, including 
stacks (see figure 2-2). 

, Executable segment descriptors refer onlyUo s^nents that contain executable instructions (see 
•figure 2-3). ' ^-"^K, I 

1. System segment descriptors refer only to segments that cKmtain_,speciai hardware-recognized^data 
structures, such as descriptor tables (see figure 2-4). \ \ 

Gate descriptors define entry points fonconwd transfers. X gate descriptor does not directly address 

a memory segment: instead it provides a. protected poin^r t(^ an ^ported entry pq^nt. (Refei| toi 

the section "Gate Descriptors" later in this chapter.) 

The^ first two types of descriptor hold, information that any operating system must maintain. The 
IaPX 286, hovi/ever, requirey-titar Hu iM ' Woma 't i t fe be in a fixed fonAal so the CPU can interpret it 
4irectly^ These descriptOTS-are-often-weated idyiiamically wt|ile a program executes (for example, a 
datai-s^gment descriptor may be created when a task neeids additional memory to store an expan^ng 
jbt4 s^BGture). I — - ^ ' • 

The second two types of descriptor are unique to the iAPX 286. They are constructed either once when! 
the system is built or once when a task is created. Code to manipulate these descriptors is limited to 
|he praoedures of a dynamic QperaUng^ system that create new; tasks. 

$ev^f^M^"rtle^dcseriptor formats-bave co mmo n fie tdsr ^ iei te f t d ds are listed first in the following! 
iisoissions of descriptor contents. | ! i ' 

PRESENT BIT 

Th'iS'BSSlean is set if the segment addressed by the descriptor is actually present in memory, reset if 
not present. Operating systems for dynamic applications that implement virtual memory must set and 
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reset this bit as program segments are brought into or eliminated from memory. Reference to a segment 
whose present bit is reset causes a fault, providing an opportunity for the operating system to load the 
segment from virtual store. (Chapter 9 takes up implementation of virtual memory systems.) In systems 
^aiidb not implement virtual memory, this bit is always set for allocated segments. 

D^CRIPTOR PRIVILEGE LEVEL ' " 7 i ff ^b- oj i^ i!;t: i v 



The value of this item defines the privilege level of the segment addressed by this descriptor. You 
control the values in the descriptor privilege level (DPL) by the parameters you give to the builder 
when creating a static system or the resident portion of a dynamic system, or by the procedures your 
operating system uses when loading segments dynamically. 



INf EL RESERVED t 



This portion of the descriptor is reserved by Intel and should always be initialized with zeros. Other 
use of this field in a valid descriptor will pre«est«QnitiaitaiBli:fy '!(i'ith fte^ other additions 

to Intel's family of processors. 
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Ifeis^field contains the phy^^liaii^»)dS^e&iii!i^iwiip#'ttie'Am x^etred to il^ 

descriptor. The 24 bits of thk)-a>^tt^ ■^^■i^^&6^%miM!t^^^^m^^i of real addresses, 'i^is 
the only place that physical addresses are used. All other addresses are relative to the physical addresses 
stored in descriptors, making it possible to relocate executable and data segments without making any 
changes to the relocated segments or to code that refers to the segments. The only changes necessary 
to relocate segments are changes to the physical addresses stored in descriptor tables. 

You can control the actual location of segments by means of specifications to the Builder or by means 
of th? algorithms your Qpe};f4.?®,s}fftep jm^,^0^4ljp9^,;ji^i^^j;, t9,_^gments that are Ipaded 

dynamically. , r ;:^jr,.i; \^-,bi>v^ /mvIh,, _ ; ni'.' 

SEGMENT LIMIT 

Segment limits prevent accidental reading or writing beyond the space allocated t^'a s^gment;i;jF]$e 
value of this field is one less than the length of the segment (in bytes) relative to the beginning of the 
segment. The 16 bits of this field make it possible to have segments up to 64K bytes long. The hardware 
automatically checks all addressing opt&Me^i^f&kmitl^Mief'^ ik)t'*iffifced'the!segmenflimte'6T 
the segment to which they' refer. This protects other-^ segments from ■such common programming errors 
as runaway subscripts. 
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Figure 2-4. System Segment Descriptor 



Note that the segment limit field has a different meaning Jor "expand down" data segments. Refer to 
the "expansion direction" bit later in tKis chapter. " \ 

SEGMENT TYPE ' [-l^l^-ij^A ^^'^ I 

For system segments, the type fi^^ai«UaggiS|BS"§cti^en kinds oi system segments. System segment 

types are 

1 and 3 Task state segment, a segment used for storing the .goiUext of a task. Chapter 4 discusse^ 

task state segments meSmtm^ . ' \ \ i 

2 Local descriptor^ttite>^^^«e kinds of descriptor tables are explained later in this 
chapter, ' y | 

The processor interprets the type field to ensure that each segment is iactually used as intended; foi; 
example, an attempt to jump to a local descriptor table is obvidusl^^a Jliistake, and the processor 
detects this error while examining the target segment's descriptor-dohng the JMP instruction. 

EXPANSION DIRECTION 

eata segments may contain stacks as well as other data structures. Stacks expand toward lower addresses 
Mtemost other data structures expand toward greater (higher) addresses. This field indicates the 
growth pattern for the segment. A ini^'^fvZBimoOteiiciiiBdiiateKtfa^ithe segment expands upward 



121960-001 



intel 



USING HARDWARE PROTECTION FEATURES 



^from tEe base address toward tfie segment fiimTvarue that is aJso cohtiiined^ih the descriptor).' A valiiS 
of one indicates that the segment expands downward (from offset FFFFH toward the limit). 

jwRITABLE ^ _ _ 



This field applies only to data segment descriptor. A value of one permits the CPU to write into the 
segment; a value of zero protects the segment from attempts to write into it. Translation tables are but 
i>ne example of data that deserve the extra-pr0teey^^lifOTde^-%y-^t^a|ge4^a read-^nly^ Segment. 

CONFORMING I I ' I 1 i 

i 1 ! , M 



fhis field applies to executable-segment descriptors only. Ordinarily (when the conforming bit is zero) 
k called procedure executes at the privilege level defined by the DPL in the descriptor of the segment 
|n which the procedure resides. When the confcHining bit of tbe called segment is set, however, the 
^Ued procedure executes at the calling procedure'it-ljriyikge level. This feature cannot be used to 
iecrease (numerically) a segment's privilege level below that defined by it's DPL. Figure 2-5 shows' 
graphically how a conforming segment works. This feature is useful when you want to make procedures 
(mathematical subroutines or run-time support procedures, for example) available to a number of other 
procedures running at different privilege levels, but when you dojiot want to provide increased privi^ 
lege while the subroutine is executing. 




■IX' ? 4:>f .-;-jiu!'>inJi' Xitnb twlta ftp, Ibw 

.■.,a...-.i.>-: ^^>^,^-^ iCT.^.,..-.. hf..,.v-... , . ■ 

l^igiAre 2<& ^ <^Rng 'SiConfomtina Segment 
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READABLE 

This field applies only to executable-segment descriptors. When reset, it prevents procedures in 
other segments from reading this code segment; the contents of the segment can be executed only. 
It| isj cQmmon, howeyer, for ^^^^^le segments to contain read-only data, in which case this bit 
must be set. ' . J . ' , , >•,) .•. . 

ACCESSED 

The processor sets this bit when the descriptor is accessed (that is, loaded into a segment i^M^er Cff 
used by a selector test instruction). Operating systems ftat im^ement virtual memory may, by period- 
ically testing and resetting this bit, monitor frequency of segment usage. This bit also indicates whether 
a segment should be written to secondary storage before the RAM space it occupies is reused.. 

Ci>lfi:BplqiTLC»ar TRANfRERd ei) A issfi} sonsislai lovsibni ns abrwoio >j ) 

'jSiv, • . <)\<: -.1 • , .. ■ ■,ir..?3b oihg 350313131 oJ aislzninJ loKnov iasJisJni bnc i->v. iiimi gnn u,!. 
Transfers of control are also subject to protection mles. Within the a^iiartl>«i'<S!S8W*ed:piiist-Bfi* taste; 
the protection rules allow unlimited access to code and data. Control transfers to privileged operating- 
system functions and to other tasks, however, are controlled by gate descriptors. With gate descriptors, 
the iAPX 286 architecture can perform functions in hardware that operating systems on other proces- 
sors must do in software. These functions are invoked directly by ordinary CALL and J MP instruc- 
tions, not by special interrupt or trap instructions. " 

As table 2-1 illustrates, transfers of control can be classified into four categories, depending on whether 
control passes to another segment, another privilege level, or another task. This classification can help 
clarify how privilege levels, descriptor tables, and tasks are used. SOT03 r A : c i'.i 

Pjiiiietesor functions th^t causf^ d&u^ itt;dil^er«(Q£BaHtM»^Hj 

• Jump instruction (JMP) 

• Procedure call instruction (CALL) 

• Procedure return instructitm (RET) 

• Software interrupt instructi<«fc(JJP')i -..^ti-, .,• i , ..ii,!:. 

• External interrupt 



Table 2-1. Categories of Control Flow Transfer 



Category 

.V, r , I,- .r.;r t<J ;jr 


SeiaiMenf 


Privilege 

■ , „L(»yeJ.M 


TasK ^ 


Intrasegment 


same 


same 




Intersegment 


different 


same 


same 


Intertevel 


different 


different 


same 


Intertask 


same 
or 

different 


same 
or 
different 


d^er^nt .. . 



Zr-T 
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Interrupt return instruction (IRET) 



Control transfers within the same privilege level may be either short (within same segment) or long (to 
another segment). A short transfer simply specifies the offset of the instruction to which control is 
transferred in the same segment. A long transfer also uses a selector to identify the segment to whiiili 
control is transferred. 

For control transfer to a different privilege level or different task, the iAPX 286 introduces gate 
descriptors. i i 

Gate Descriptors 

A gate descriptor is a type of descriptor used only for tramsferring ctmticd flow to instructions in another 
segment. Gates provide an indirect reference that is useful for bfl0S^M(Al^h>tl(^flikHpil^&3f?®)(' 
requiring interlevel and intertask control transfers to reference gate descriptors, the iAPX 286 provides 

two additional protection features: . i 

1. You can hide a procedure by not providing a gate for its entry point. 

2. You can control ^ccess to a procedure via the privilege assigned to the gate. This allows hiding 
critical procedures from untrusted Software. • 

Ifigure2-f Ul.u5jtrates the fprni^t^of 8 gate,.dg|<^^ i, ,.^,,^. , 

qu .i ,1 ; . ■ . J - /• '-i TO ugsliviiq i^jrflofiii ,itijfa,^f. • •nmov 

DESTINATION SELECTOR - : 

For call, interrupt, and trap gates, this field contains a selector for the segment descriptor of the desti- 
nation executable segment. For task gates, the selector in this field points to a descriptor for a task 
state segment, and the RPL field is not used. ';i j.i, . • . 

DESTINATION OFFSET ( lij,,. , 

For call, interrupt, and trap gates, this field contains the offset 6# iAfe'aitry point whhiti the'd^idHiSon' 
executable segment (not used with task gates). ,1 

WORD COUNT 

For each privilege level within a task, there is a separate stack. For calls through a call gate, the 
processor automatically copies parameters from the stack for the calling procedure's privilege level to 
the stack for the destination's privilege level. In this field, you specify the number of words to copy, j 

GATE TYPE 



For gate descriptors, the type field distinguishes 



i mong the four kinds of ^ ates : 



Call gate 

1 Task gate 

2 Interrli^t gkte 
3— Trap^ate - 



Jrtc-isHitj 



Jnrt'lf*.'!;: 
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WORD COUNT 
ONLY FOR TYPE -00 



DESTINA' KM SBfCTOR 



kTION OFFSET 



f JRTWE 



X J X 



=01 0(1*1, 10' ;■" 



T3fll ,73fi 



n'.'ll. J J/ 
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PRESENT BIT 



.jQunelnl Isnisticn 



Since a gate descriptor does not refer directly gate <ki!ii^|%4 

not necessarily indicate whether a segment is pr^senOt oui be ia^mf^%meT purposes, however. Refer 
to Chapter 1 1 for an example of using the present bit to facilitate late binding. 



Control Transfer Mechanisms 

Tibfe 1-2 suniiftai?2es the me*;KanB^4dftdi^^ 

Control transfers within a segment function similarly to intrasegment transfers on the iAPX 86,88, 
except that the processor checks that the destination address does not exceed the segment limit. 

Figure 2-7 illustrates a change in control flow between segnwnts at the jgrivilegc^ Jevel. Any of 
the following instructions can effect such a transfer: - . ' _ 



J M P offset selector 

CALL offset selector 

RET ; (offset and selector taken from stack) 



The selector selects a descriptor for an executable segment. The DPL in the target segment's descrip- 
tor must be the same as the privilege level undef'Wfaicit 1it«Jeyfil^«^«t is hmning. A CALL or 
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Table 2-2. ConfroTTransfer Mechanisms 



Transfer 
Type 


Operation 

TO 


Descriptor 
Referenced 


Table 


1 Intrasegment 


JMP, CALL, RET 


^none) 




! Intersegment 

1 (*) ' 

! 
j 


JMP. CALL, RET, IRET 


code segment 


GDT/LDT 


OALL, JMP 1 

..C. IKOW , . ,1 
I V iry. . n»,-, « .■ '1 


1 ; 1 1 

call gate j 
a<iVT (^aeK|PL) 1 


\aU 1 /LU 1 


INT instruction, 
external interrupt, 
; or exception p,.,,,,^,^., 


trap or 
interrupt 
,., gate (same PL) 


IDT 


■j 

Interlevel 


CALL 


call gate 


GDT/IDT 


i 








INT instruction, 
externalinterrupti-- i j' - 
or exception 


trap or 

interrupt 

gate 


IDT 


RET, IRET 


code segment 


GDT/IDT 


Intertask 


CALL, JMP, IRET 


task state 
segment 


GDT 


CALL, JMP/?£-->saO ©feS 


* f -tKMlate 


GDT/LDT 


INT instruction, 
external interrupt, 
exception 


task gate 


IDT 

• ■ ■■:;p' 



* Includes cases in whicii the target segment is incidentally the same as the calling segment. 



JMP instruction may also reference a call gate. If the target executable segment is at the same privi- 
lege level, no level change occurs. . .. . . 

For transfers of control between segments at different privilege levels (as illustrated in figure 2-8) t^ere. 
are three differences: 

■ ■ ' ..i .- - ■ '■. '! ,';si i fnan ' -.• i ; ■■/.rir- j 

• Only'tfce>following instrUCtidhs"eaii%i uB6#b'' " ''^^ ' - 

CALL offset selector '''"^'-f '''^^^^^ 

p £ y : ;*r<r>;i! k iJiu'v. L'-: i . . i ' ■■ - [ ■• " 

Jumps between privilege levels within a task are not allowed. 

• The selector does not select the descriptor of an executable segment but rather selects a gate 
descriptor. 

• T 'Th6 offsefopcnind must bep'^ilt.butls igndceA.. 'ij tsv-j^ 
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Figure 2-7. I.ntraleyel Control Transfers 



Privilege Rules for Gated Intersegmertt Transfers 

An intersegment transfer through a gate involves four privilege level fields: 

ThiB cun-ent privilege level (CPL) of ^le enrircntly executing segnient • ' 

• The requested privilege level (RPL) in the selector used in the CALL 

• The DPL in the gate descriptor , 

• The DPL in the segment descriptor of the target executable segAemt 

A transfer is valid only if the following relationships among privilege level numbers both hold: 

MAX (CPL, RPL) < = gate DPL 
target pPL.<:=CPL 

Figure 2-9 illustrates both valid and invalid attempts to perform an interlevel transfer. Path E4,G5,E7 
is not valid because the privilege level of gate G5 is numerically less than that of segment E4. Path 
E4,E8 is not valid because all interlevel transfers must pass through a gate. Path E4,G4,E6 is not valid 
because the privilege level of E6 is numerically greater than that of G4. Only paths E1,G2,E2; E1,G1,E3; 
and E2,G1,E3 saltisfy the privily rale abowsi ' • > ■ "; • < i;, ; i > 
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Figure 2-8. Gated Interlevel Call and Return 



DESCRIPTOR TABLES 

A descriptor table is simply a segment containing an array of eight-byte entries, where cach ent^yis a, 
descriptor. Descriptors are stored in one of three classes of descriptor table: 

• Local descriptor table (LDT) '" 

• Global descriptor table (GDT) 

• Interrupt descriptor table (IDT) 

The descriptors in these tables define all the segments in the system. Each tdble lial"' ^ Wnkfe wpper 

limit, so the size of the table need be no larger than required for the actual number of se^ents used 

- .. : ' ■<• ' ■iiT^^sn't (ft, miiAi-jq 01 ilqia^il^ tsiiunm bill. hiiiiJ cil' ■ •.]'\ ' 

YOBudj^ne the initial contentsiQ^(l;ii^#t093taMfs through the Builder. An operating system for dynamic 
^fli@ti®is may change the eeweits.oftstoscf^tor tables and may create and delete LDT's as tasks 
come and go. Correct management of descriptors is the heart of pwteetionMonthe iAPX 286. 
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Local Descriptor Table 

An LDT contains the descriptors that are private to a task. Each task may have an LDT. The LDT 
keeps the descriptors private to one task seimrate from those private to other tasks. A task cannot 
aormatly gain access to the segments defined by another task. A local descriptor table may contain any 
of the following types of descriptor: ', 

j» Data segment 

[• Executable segment 

!• Call gate 

,• Task gate 



IThe executable segment and data segment descriptors in an LDT normally refer to segments private 
to a task. C " ' ' - . 

programs. 



to a task. Call gates and task gat^-ln a^ prov|lg^vate 'ie^jtry points to other procedures and 



The processor uses a task's LDT automatically for certain addressing operations. The base address and 
limit of the LDT segment of the executing task are kept in the LDT register. Only two operations ar^ 
available to programmatically change the contents of the LDT register: 

During a task switch operation, the processor loads the LDT register from the task state segment 
I (TSS). ' 

The LLDT instruction loads the LDT register directly. The LLDT instruction can be executed only 
at privilege level (PL 0). Initialization procedures use LLDT to give the LDT register its initial 
value. Note that if you change the LDT regist^^ou must also change the LDT selector in the TS$ 
(refer to Chapter 4). An operating system may nete^ t© change the LDT register temporarily to gain 
access to the address space of another task when passing information between tasks. 

You can use the SLDT instruction to read the contents of the LDT register. Operating-system proce- 
dures that operate on LDTs may usually be called from any task. These procedures may use the SLDT 
I instruction to find which LDT belongs to the^-ettrrent Jask. Iij PL/M-286, the built-in variable 
« LOCALSTABLE gives access to thfe LDT regist^. I •-—J \ « 



An LDT may contain up to 8,192 descriptors (the number of 8-byte descriptors that fit into a maximum- 
sized segment of 65,536 bytes); I J. J j,^ - '« ■«.■—* ' 



Global Descriptor Table 



(Descriptors that are shared among tasks reside in the GDT. There is only one GDT for the entir^ 
jsystem. The GDT can contain any of the following types of descriptor: i 

• Data segment ■ 

• Executable segment 

I 

> Task state segment 

!• Local descriptor table segment 

i 

)• Call gate 

• Taskgate : r-- iV i^^jjiis?;';;! Diisv .H-i 
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Since the GDT is shared among all tasks, its enfries'afe usually protected. The privilege-level field in 
each descriptor provides this function. When operating-system functions are distributed among and 
shared by all tasks, the executable segments and data segments of the operating system are normally 
[kept in the GDT. Call gates then provide controlled access to privileged operatinji system functions. | 

'The processor uses the GDT automatically for certain addressing operations. The Ixase address an4 
limit of the GDT are kept in the processor's GDT register. Only the LGDT instruction 
(RESTORESGLOBALSTABLE in PL/M-286) can alter the contents of the GDT register, and the 

I LGDT instruction can be exeCTltferdllrat'Pt'iy t?^rt»rTll g u p^ 

iThe SGDT instruction (SAVESGLOBiyili^Si^S^ 51ms^M-286) reads the contents of the GDi" 
' register. ' 

P^QWf, pay contain up to 8,191 descriptors (the number of 8-byte descriptors that fit into a inaximuni- 
nsee-segmmt-of "65^536- bytes).' The first entry cannot- be used as-a descriptor. (A nuU -selectcu' & 
identified by the fact that it refecs tdtys^i^JtotrjKai tS^^]^!)-;,! t 



Interrupt Descriptor Table 



When processing an interrupt, the processor refers to the IDT to determine what interrupt-handling 
code to execute. Each interrupt iS'SSSdciated-trithfan interrupt identifier, an integer that rangies; from 

0-255. The interrupt identifier is supplied either by the INT instruction or externally by the processor's 
INTA cycles. The interrupt identifier indexes an entry in the IDT. An IDT entry may be 

• An interrupt gate 

• A trap gate 

• A task gate ^' ' y t * 

In a manner similar to executable segment and data segment descriptors, each gate descriptor has a 
descrijjtoi; privilege level. The DPL qf a descMtor m tiie^I^Tdetermines^ the privilege required to 
execiite ahl!^ ft uiSfructiori^wheire'tf is tfie ffll^^i^^Msffi^^iWt C(OT^^xAids to this descriptcJr). 
This use of privilege levels prevents unauthorized programs from invoking interrupt handlers. 

The processor locates the IDT by way of the IDT register. The IDT register can be changed only by 
the LIDT (load IDT) instruction (RESTORESINTERRUPTSTABLE in PL/M-286). Only PL-0 
procedures (i.e., the operating system) can execute an LIDT instruction. 

The SIDT iflstracti»n (SAVE$INTERRUPT$TABLE in PL/M-286) reads the contents of the IDT 

r^iitcr.- '"-if'" - J n\ 

' ■ '"■ i'- = J'1>1 ne --^ .i'l IK ■.fi . i .^1 .,• • !: 'il'^.Ti./; ' ,j -ni^j'i I'-.r, 

Refer to Chapter^ 6 arid 7 fo?rko^«ltjiMdHMyrflfitiMHito*dw«^ " ■ r " 

SELECTORS 

A selector references a segi^jj^tjUidgepj^^ 1^ identifying the location in a descriptor table where a 
descriptor for thal^gment isjS|(|^ bsjohl's-. o ^ . ! 

Format Of Selector i!^!:ivi\J>i 

See figure 2-10 for the format df af^^sgledRrf.i^ ' • ' ^ "^i^ . 
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T" 



INDEX 



Tl — TABLE INPICATOR . , , 



;1 ' 



Figure 2-10. Format of a Selectof ! 



INDEX 



The fiicjex field of a selector specifies a descriptor in either the GDT or the task's LDT. The index field 
«ia*f siafe, on values from through n— 1, wba* n is 4hei winder of descriptors in the table. The 
froceisffir camp&tm the indent 'wi^h liait &{ ttede^tipt&f itkble't3?emU(s that the index ref^i tdia 
defined descriptor. 



TABLE INDICATOR 

'^is bit item tells \»^ieh 4«&ripior'taile'iis indexed by the selector. A valii6''<^ zerti specifies the GDT; 
pn^-S^ecifies the LDT. (The IDT cannot be referenced via a selector; only via ftM it^et^fv^l idei^i^^'T) 

^REQUESTED PRIVILEGE LEVEL .^T -.m.;v-i T^! j;jt ;o yc/a -.^ T'r ; i.m^ : 

Selector privilege if specified in the RPL field of a selector. Selector RPL may establish a less trusted 
privilege level:^^-,the current privilege level for the use of that selector. RPL cannot effect an increase 
in privilege. A task's effective privilege level is the numeric maximum of the RPL and the current 
privilege level. For example, if a task is executing at PL = 2, an RPL = 3 reduces the task's effective 
privilege to level 3 for access to that segment. On the other hand, if RPL = 1, the task's effective 
privilege level remains at 2. 

RPL is generally used by an operating system to ensure that selector parameters passed to the more 
privileged levels of the operating system do not give access to data at a level more privileged than the 
calling procedure. The RPL field is a convenient place to store the privilege level of the procedure that 
originated the selector. Any use of the selector can be restricted i!6?ffi6'it^^'anb>i*'ed tts originaW/'^ 



The ARPL instruction (ADJUSTSRPL built-in function in PL/M-286) allows the operating systjero to 
set the RPL of a selector either to CPL or to the privilege level of the originator, whichever is (numer- 
ically) larger. Refer to Chapter 13 for more information o.n.jt]j%iys%(^RJPL.:, j,- 
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Null Selector 



A selector that has a value of zero in both the index and table indicator fields (i.e., appears to point to 
the first entry of the GDT) is a null selector. You can load such a selector into the DS or ES register, 
but any attempt to reference memory via that register causes an exception condition. 



, -hi Ual s If 



ALIAS OESCRiPTORS 



The need arises in dynamic applications for the operating system to maintain more than one descriptor 
for a segment; however, care must be taken to preserve syslem;i9*«@it3CieKi4ipRdBotjon. 

As an example of the need for an alternate descriptor, consider the case of an executable segment. 
Ordinarily, the processor fetches instructions from an executable segment that is typed execute-only. 
However, if the operating system supports a debugger, the debugger needs to read the executable 
segment in order io display its contents. The debugger may also need to write to the executable Segment 
in order to set br^sikpoints. If the debu^er tries to use an execut&^y !|^ttneiit desc^pt^ to read 
from or write to the segment, the jn'ocesscH' delect a poteetet emeejgi^m. "t^^b^^ ase mstt 'sigRicnt, 
the debugger must use another descriptor that identifies the segment as a data segment. Figure 2-1 1 
illustrates this situation. 



:>I.U. 



The use of more than one descriptor for a segment is known as aliasing. Descriptc|pi iise<} in this way 
are known as <]//a.;ef, because they provide alternate names for segments. 



APPLICATION 
LOT 



EXECtTTEONLY 
CObEfKMENT 




|mstruciions 

rT7 



IZ, 




o.s. 

pEBUGQER 
I IDT 



DATA SEGMENT 
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Explicit Variation of Type 

Figure 2-1 1 illustrates ooe kind of need for aliasing: the need for a different type specification for a 
segment. Figure 2-12 shcWls^ another example of the same need. In a dynam«:^iappl!c^bn,ntie dp^ilijig 
system may need tb modtty*'^ -©DT, the IDT, TSSS/a«^^EpTs. Changing the inteitl^^Kahfflir'fbr 
a specific interrupt vfectof Ve£f(i^Ss*^anging the lE)T7'W}fi!ff flie operating system placed' a"fi¥* isS|n\8fit 
into the address space of a task (as, for example, when transferring an 1/0 buffer from an I/O task), 
it must update the task's LDT. Starting a new task may require modification of the GDT to add 
descriptors for the new task's LDT and TSS. 

With the iAPX 286, however, it is not possible to md or write a syst^ segment by loading its selector 
into DS or ES. This restriction prevents indKcriiniaate use ot system segments within the operating 
^SyStMS^iilieb tESe of a system segment Teqmm*(tBev^iltit^^^^S^iim4!e^'A^ 
fies the system'segment as a rfatoMgm^.'' ' "■^' •ft'- • >: tTv.Jr^i .,•! vu'; : ■ , / r ; 

The Builder allows for defining aliases for system segments. The Builder, by default, creates data- 
segment aliases for the GDT and the IDT at fixed locations in the GDT. 

ji^te. tJb&V^li^l^ for descriptor tables should have PL in order to maintain the integrity of the protec- 
^on ^ec^banisQi; otherwia:, procedures outside the operating system could indiscriminately change the 
^lit^pts of descriptor tables. 

Variation of Length 

As illustrated in figure 2-13, aliases for a segment need not always have the same length. In the case 
shown, the processor's use of a descriptor to a TSS requires only that the segment contain 44 bytes. 
However, the operating system maintains another descriptor that includes additional information about 
the_task. ^ 



V 



a ALIAS GDT 
ALIAS LOT. 
ALIAS ID^ 





• AUAS FOR GDT SHOULD ALWAYS BE AVAILABLE TO KERNEL. 
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TASK PRIORITY 
SCHEDULING PARAMETERS 
MESSAGE QUEUE POINTERS 
RESOURCE POOL POINTERS 




, J a 71 q J ; 1 ^ 
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'Sharing Segments among Tasks 



I - l3o3fls',(.t 



Yet another reason for using aliases is the need for sharing a segment among tasks. Consider an appli- 
cation in which a memory-mapped video display shows status information for a production process. In 
this application, there are two tasks, each monitoring different aspects of the process but interleaving 
data on the display (see figure 2-14). Figure 2-15 illustrates how both tasks can access the memory 
segment containing the display buffet. , ,^.t ,^^1 3»Kn,-,>t(; rtK iSi./oT- ■ ■ 

YoU'can find segment sharing needs of this sort in both static and dynamic systems. Note that there 
are other techniques for segment sharing that do not use aliases; for example, placing the segment's 
descriptor in the GDT, or permitting tasks to share a single LDT. The aliasing technique illustrated 
here has the advantages that 

• No other tasks have access to the display buffer. (Putting its descriptor in the GDT makes it avail- 
able to all other tasks.) 

• Other segments in each of the tasks remain protected from the pther task. (With a shared LDT, all 
segments of each task are accessible from the other.) 



Protection and Integrity with Aliasing 

• : y.jb bat. ?TOf«fnv»t> ^'rfi.'ni.nRr' of 'w 

.1'- -Tj rti-: . 

Vou must use aliases with care; improper ii^ 4^ compromise the protection and integrity of your 

system. - ; '1 ^ ^ ...i 



121960-001 



inlel 



USING HI»HMWARE«lilREeT«eN FEATURES 



FUIIIM£VEL SENSORS 



TEMPERATURE SENSORS 
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Figure 2-14. Application of Ssgmsfit Sharing 
PONTROL AQCESS TO ALIASES 



When you use an alias to provide an alternate type for a system segment (to write to an LDT), any 
procedure that has access to that alias also has unlimited power to affect the entire system. Therefore, 
in constructing an operating system that uses such aliases, you must restrict them to the highest prjvi- 
fege levels of the operating s^sl^^' that is, the DPL of such aliases should always ^ zero. 



PLAN FOR CHANGE 



When you design a dynamic system that uses aliases for segment sharing, you must consider what will 
happen when there is any change in a segment to which aliases are pointing. For example, when a 
segment is relocated, all descriptors pointing to the relocated segment must be updated. When a segment 
is deleted, all aliases to it must be nullified. Chapter 5 presents a strategy for handling these changes. 

, ■ .... . J J.i ; 'HOT !■.::..!..' 



EXAMPLE OF DESCRIPTOR MANIPULATION 

As an example of how to manipulate descriptors and descriptor tables using an alias, consider the 
procedures POINT_AT and NULLIFY in figure 2-16. POINT_AT creates a descriptor at a given slot 
in the GSIT;. NULLIFY injray^t(^ia^i;$^i^|^4nn1fceiiP7jc^i^Attti^de^ use in connection mth 
POINT_AT to prevent accidental use of descriptors that are no longer needed. 
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Figure 2-15. Aliases for Segment Sharing 



NUU-IFY invalidates a, descriptor by writing a value of 80H in the access rights byte. A value pf 8QP 
is invalid because it indicates a system segment of type zero, but no type zero is defined for sysfeiji 
segments. , , . . , - ■, 

POINT_AT purposely loads the access rights byte of the descriptor last, to ensure that an accidental 
use of the descriptor (as might occur if an external interrupt gives control to another procedure or task) 
does not find panially complete;itif(MMfttiaQi>ii$i»ji^®iiiliifc:Aiit}olAiEiii^ 

.'. - ji-i' -31 /fiiri ■ 

These procedures do no checidiig>9C^the privilege level of the caJiog^^cedure, and they freely create 
descriptors of any type (exc^ gntf jeU^<aiRt9r^i»n4.«»y PJWsf ^Wl^tafi*U>6y,are suitable for use 
only -at PL Oi As long as no gates fer'^ese proi^iffes^afe'iurqiiidsd at t^Aer -privilege level, they can 
be called only by other PL-0 procedures. For an example of how you might use such procedures, refer 
to the example of a memory manager in Chapter 3. 

When writing code to manipulate descriptors, you must be careful about changing a descriptor that is 
currently loaded in either of the processor's data-segment registers (DS or ES). Either disable; inter- 
rupts or move zero to the register before changing the descriptor, for example: 

MOV DS , 

Failure to do this leaves open the possibility thafTHiP^a^B^ilA ^Me^iWf^m&y cause the processor to 
relca;d the segment register using the partially riiodtfi^lla«;f^or: When coding in PL/M-286, use 
the compiler's CODE option to view the way the generated code handles the DS and ES registers. This 
situation does not arise in the present example. DS points to the data segment that contains the sole 
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USING HARDWARE PROTECTION FEATURES ^-"i- 

global data Item GDTA_SEL. PL/M-2WuleslST^TriKrMSSrwiaa& 

the descriptor table via its alias selector causes PL/M-286 to load ES with the alias descriptor, thereby 

ensuring that ES does not contain the descriptor to be modified. 



Remember that once a descriptor has been modified, it cannot be used to access a segment until it is 
1 loaded into a segment register. 

i ' ■ / \ 

j r / \ - = 1 

jBe aware also that in a multitasking system, changes to shared segments (such as the GDT) must be 
jsynehrenized. Synchronizatiyu is. Ihe^ subject, of Xhaptet.. 5, JTbjs. example does not provide for 
synGhr0njzation. 1 I < sny'r- j "| — _ — J j 

SLOT MANAGEMENT - ' ; 



The previous example assumes that the caller of POINT_AT already knows what descriptor-table slot 
to use. Often, slots can be reserved in advance for specific operating system and applications functions. 
But in general, dynamic syMenw-requ-tre-that-t'he-epefating-system dynamically allocate descriptor 
table slots. r;'Ti'";C' J^-sirip-iS noV asa,,; -■:"<■ " -r ; , ' 



Figure 2-17 illustrates a way of identifying available slots in a descriptor table. A value of zero in the 
access rights byte is invalid for any descriptor, so it can mark a free slot. A value of BOH (as used in 
the previous example) is also invalid and can mark a reserved but unused slot. ' ' ' 



In larger systems, the time needed to search a descriptor table linearly for free slots may become 
excessive. Shorter search times may result from linking available slots together in a manner similar to 
that shown in figure 2-17; Gontiguotis free slots are treated as a block, with a count of the numb6¥'df 
M.t}ts4k thk Rm and last sMs': #^ib b^^L (Mr Aifr^tlA Um '^miM U Ats mittvM nw<M^ 
saVailsWIe descriptor slots. Since aviiteMe 'descriptor slitsi-Sft^tilrt Wi^ii'typ# c0de; tliis toe %Siife 
reserved ivord does not prevent upward cbmpatibility.) AlfA^*^%teete''krfe4inke'd in a WrctilaH t*^ 
way list that includes the list header. The list header can reside at a fixed slot location that is the same 
in all descriptor tables (in the case of figure 2-17 the list header is at slot number one). Algorithms 
normally used for managing memory space may also apply to blocks of free dessffipi*^. Refer to 
Chapter 3 for an example of such an algorithm. ' ' 



It is convenient for the operating system to use adjacent descriptor slots for related purposes; for example, 
4^ locating together all the descriptors that the operating system uses for one task, the operating system 
«an qiuickly find any of those, deicriptCjis as long, as.it,]£nQ>Ss:tte4Q$ajti9n,Qf am. Therefore, .the algorjthjn 
4<ed for sl@t fflaaagement AsrfAiflWftWne a#w6nlfr^f^i«te yf0*;AifleiWl>dc. Tb© prb«*i»res used 
manage free slots should tfcsrhfcvs s par»Hi©tertJ|a,t sf^jFies tb© mumbBr of adjacent slots, i. 
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PL/M-286 COMPILER 960-505 date PAGE 1 

system-ID PL/M-286 Vx.y COMPILATION OF MODOLE POINT 
OBJECT MODULE PLACED IN :J'L:..EftINTi«QBa *.«*»».....*»...».. «\ 
COMPILER INVOKED BY:. .^LM2.86.^86, ^ aJteiD 

. -els Jo !? " : ; 

, $ PAGEWI^!rH(T[i()..;!r;IiTLE(^960-5f St) aliNCIiqD^nitSAsNUCSU 

S NOLIST ■ ' -. 1 ,.A:-T:;il:- , fcL'i 

1 POINT: DO; ji.- ,r,jt;9 WOT!' i.i.-.u;.iC 

/************♦*************************««****** 

/* Global declarations. */ 

2 1 DECLARte DESC^T" LITERALLY 

■LIMIT WORD, ;u 

LO_BASE WORD, ,, /* For^&^:i<?.f a descriptor. */ 

HI_BASE BYTE, 

RIGHTS BYTE, l'"l.J-. . t .hJ ^'-'C 

SW_RESRVD WORD'; :3^. flT'. 

3 1 DECLARE DT_SIZE LITERALLY '200' , 

. GDTA_SEL SELECTOR, /* Points to GDT alias */ 
GDTA_WSEL WORD AT (iaGDTA_SEL) 

INITIAL (8), /* Slot #1 by convention */ . 
GDT BASED GDTA_SEL (DT_SIZE) ■■ • 

STRUCTURE (DESC_STR); ' 

. 1/1 ..s-ia.-; ■; - ■;) rc^ ;•. 

^** ******************************* ***1i*1t_*.1^i^1t*1i****ii**it* / 

/* Subroutine to determine either thj^^ ftligii^ for */ 
/* the GDT or the alias for thi s tasW's 'LDT, */ 

/* depending on the TI bit in SEL. ,*,/ 

4 1 FIND_DT_ALIAS: PROCEDURE (SEL) SELECTOR i • 

PUBLIC REBM7|tANT; ~ 

5 2 DECLARE-SEL -.j,,, ■.■js^pIjiSB^Savijl 

WSEL wmo AT teSEt.); 

6 2 DECLAKB' liDTjSgfc: SELECTOR, n , , 

LDT_WSEL WORD AT (@LDT_SEL); 

7 2 . IF (WSEL AND 0004H)=0 t.-_ 

THEN /* It's a selector to the GDT. */ 

8 2 Rmm» S&fh_S^t'! ,0!KJW ITOja 39AJ"an 

9 2 ELSE DO; /* It's a selector to this task's LDT. */ 

10 3 LDT_SEL=LOCAL$TABLE ; /* PL/M 286 built-in; stores a 

selector to the GDT descriptor for this task's LDT. */ 

11 3 LDT_WSEL=LDT_WSEL+8; /* Add 1 to index field. */ 

/* By convention,, next slot holds alias. */ ' t 

12 .3 RETUMI MWi^SEfc*;;. • ■ r , , „ i r-, - ; , j . 

13 . 3 • END;^ •!,\T . •■ — '. ' ,' vs ^ CTHr?'!. 1 i Toj-:! 

14 2 END FIND_DT_ALIAS; :t'ai"i':ii 

$ EJECT 
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PL/M-286 COMPILER 960-505 date PAGE 2 

■ / i O'-: 3j J0OM 30 Ml ■ i'f"-.' ' . - " ■ =• 

/* create a *eScfi^^t^f€ ^%#4rHh.ot" &'^^ */ 
/* segment, and return selector that points */ 
/* to that slot. */ 

15 1 P0IN'P_AT: PROCEDURE (SLOT , RI GH^S,' "t'ttW'1k(A)|i_,PTR , LIMIT) 

PUBLIC REENTRANT; rt.''>^ 

16 2 DECLARE SLOT SELECTOR, 

SLOTW WORD AT (esLOTJj /* Alternate type */ 

'" ''rights byte, 

phys_addr_ptr pointer, 
phys_addr based phys_addr ptjt structure 
(lo_word word, " 
hi_word word) , 
limit word; 

17 2 DECLARE SLOTI WORD, /* Slot index'*/ 

DTA_SEL SELECTOR, /* To be set to either 

GDT alias or LDT alias. */ 
DT BASED DTA_SEL CDT_SIZE) 

' ' 'L'^ i ■^W^l'^^ (;plfC2_fTR) ; 

18 2 " -tJTSf 'B'EL = FIND_DT_ALIAS (SLOT'iV"'^'" 

19 2 SLt^i' = SHR (SLOTW, 3) ; /* Expose Ihl^ex value. */ 

20 2 DT (SLOTI) .LO_BASE = PH YS_ADDR . LO_WORD; 

21 2 DT (SLOTI) .HI_BASE = LOW (PHyS_ADDR. HI_WORD) ; 

22 2 DT (SLOTI) .LIMIT = LIMIT; •'•>*^' 

23 2 DT (SLOTI) .SW_RESRVD = 0; - 

24 2 DT (SLOTI) .RIGHTS = RIGHTS; '' ''^ ' 

25 2 RETURN; 

26 2 END POINTAT; 

^******************************************************* ^ 
/* Inwama&^'lfescriptor ifltffexea' by SLOT. */ 

27 1 NULLiF?: mocmmm'--mmy public mss****!*;' 

j'jfs ""'i.'Si; r-i. riBow ■■ V.'.l 

28 2 DECLARE SLOT SELECTOR, i 

SLOTW WORD AT (?SLOT ) ^^^'•■jMter Bate type */ 

29 2 DECLARE SLOTI WORD, /* Slot index */ 

DTA_SEL SELECTOR, /* To be set to either 
> = o. i^j-i^;.-. GDT alias or LDT alias. */ 

STRUCTURE (DESC_STS)'^ ■ 

!=J3?v, • ■ . 

30 2 DTA_SEL = FIND_DT_ALIAS (SLOT) ; " 

31 2 SLOTI = SHR(SL0TW,3) ; /♦ Get index part of selector. •/ 

32 2 DT (SLOTI) .RIGHTS = 80H;/* This invalid value prevents 

use of the descriptor. */ 

33 2 RETURN; 'a_-v,i-i ov. 

^ ' J I' ' ■ 

34 2 END NULLIFY; 

/**************************«**************************** ^ 



Figure 2-16. Descriptor iManipulation Exampie (Cont'd.) 
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MODULE INFOBMATION! j j ^ 

CODE AREA SIZE = 00CAH 

CONSTANT AREA SIZE = 0000H 

VARIABLE AREA SIZE = 0002H 
MAXIMUM STACK SIZE 0^181! 
129 LINES READ 

PROGI^M WARNINiSS I 

PROGRAM ERROR^ j 



DICTIONARY SUMMARY: 



I 



202D 
0D 
2D 
i4D 



96KB MEMORY AVAILABLE 
5KB MEMORY USED (5%) 
0KB DISK SPACE QBEO 

END OF PL/M-;1286 COtfPllSfSSiff 
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Figure 2-17. Avaltable Slot List 
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Real Memory Management 



CHAPTER 3 
REAL MEMORY MANAGEMENT 



In dynamic applications, when tasks begin and end frequently, the operating system is responsible for 
allocating memory to tasks. Without the control that an operating system provides, independent tasks 
cannot be trusted to share the system's memory harmoniously. The iAPX 286, through the descriptor 
mechanism, giyCs the operating system the power to control memory usage. For static systems, you can' 
use the Builder to allocate memory. This chapter presents ah example of how to 'manage real memory 
dynamically, using dynamically created descriptors. 



MEMORY MANAGEMENT FUNCTIONS' ' < 

Procedures at various levels in a system have a need to get memory for their use 
^hat use memory dynamically include l.:.:^..] 

• Loading the code and data segments for a new task 

• Creating the TSS and LDT of a new task 
■ Expanding an application data structure 

• Expanding system stack segments^hen stacks grow too large — 

• Allocating buffers for a newly opened Hie - - 

In allocating memory statically using the Builder, you or the Builder must keep account of what memory 
locations are available and what locations are used. A dynamic memory allocation module must do the 
same, but, in addition, it needs to reuse the space vacated by tasks that have finished- Even tasks that 
are stiU executing may no longer need all of the memory they once were using, so you need to provide 
some means for them to return .^at space dynamically. The need to reclaim formerly used memory 
space provides cons^ei^tble ch^lenge to operating system designers. 

Protection usually requires that segments not overlap. The operating system should accurately keep 
track of allocated memory to prevent new segments from overlapping current segments. 

Allocation of memory to tasks in a dynamic environment is complicated by the facts that segments 
have differing lengths and that the order of creation and deletion is unpredictable. Consequently, after 
a number of tasks have come and gone, memory becomes fragmeoted, as illustra^ m h&^i^^XrM 
becomes increasingly difficult to find free areas large enough to accomodate requests for space. It may 
happen that no single free area in all of memory is large enough to fill a request for memory even 
though the total of all smaller available areas is larger than the amount needed. Knuth (see "External 
Literature" in the Preface) discusses how various memory-management mechanisms can, minjmw^ or 
magnify this problem. 

Memory management on the iAPX 286 differs from memory management on other processors in that 
descriptors must be constructed to access any region of physical memory. 

■L' , ■ ~ , ' ■ I. ■ 'J. ■ It. -jil.oTjrljijrfw !):..■ . . 

EXAMPLE OF A MEMORY MANAGER h.uJo 3 a ^ ^^'^^ 

As an example of how a memory manager can manipulate descriptors and segments, consider a memory 
management module that implements a version of the "first fit" algorithm (as described by Knuth) 
and combines adjacent free segments as a way to reduce fragnasatotialr. Thisi example empk^ the 



. Some of the functions 
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Figure 3-1. Memory Fragmentation 



"first fit"' klgbrithm because it provides an opportunity to illustrate how to create descriptors dviiaitii-^ 
cally to access free memory areas, not because it necessarily performs best in any spec^ic appllcatioii. 
Knuth discusses other algorithms, including the "buddy system." . . ■ ->£■ ■ 

Figure 3-2 illllsfrates conceptually the structure of this module. Hidden inside the riibdule are the list 
of available memory space, the aliases that permit modification of the GDT and LDTs. and the space- 
management algorithms. The PUBLIC procedures ALLOCATE and FREE are the only interfaces 
v^itli the World outside the ifiodule. , i . . . 



Data Structures 

Figure "3-3 illustrates the data structure 4mplcmented"in this example memory mana^r. Oi&'wiar^ 
tags bound every memory area oh'^Ma»^3SM'ii^Mih''iiid:ini6kH6u'ndary tags indic'atfe WKetfife'Wfe 
area is free or in use by some task. FreS%if^*s8^chained mto a two-way linked list that uses physical 
addresses to point to the next and prior segments in the list. The size of an area (in bytes) is stored 
with the link addresses in the low-addressed end of the area. At the high-addressed end, a physical 
address points to the beginning of the area. ' ■ RMii',. 

■ ■ . , '. . w in'"''.;'- 

With boundary tags at both ends of every memory area, the memory manager can, when freeing a 
segment that is no longer needed, ^sitf determine whether either of the adjoining areas is free. Figure 
3-4 illustrates how adjacent free m^M tian hg cop^bined t<b;.reiu«« memtxy-Mgrnentatioa. " f 

Figure 3-5 illustrates that boundary tags are invisible to procedures outside the memory management 
module because the tags are not within the base and limit addresses in the segment descriptor thatnth© 
memory manager return* to tte catter: • • - . ' • - . . . v 
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Figure 3-2. Information Hiding in iMemory-IManagement Example 



This memory manager does not maintain descriptors to free segments; instead, it creates descriptors 
dynamically when it needs to address the boundary tags and space-management linkages. This policy 
minimizes the number of descriptors in the GDT. Note that as a result, free areas may be larger than 
64K bytes. - ■ 'i • -• 

Physical addresses are stored as double words (DWORD) to take advantage of double word arithmetic 
in PL/M-286. In an actual implementation, you may wish to store physical addresses in three-byte 
fleids'to save space, bat you would need to implement arithmetic operations for three-byte operands. 

The total size of the memory-management items assodated with each ffee a^T%^SO bytes; therefore, 
to ensure that no memory area is too small to contain the memory-management items, this algorithm 
chooses the size of the allocated space to be a multiple of the next integer greater than 20 that is also 
a multiple of 16. This number is identified as BLOCK_MODULUS. 
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The memory manager maintains physical-address pointers to the first segment in the available segment 
list and to th?5 |ast. It also m^int^^ip^a "curr^t ^railable" ^uiter that corresponds to Knuth's "rovii^^ 
pointer." " ' " ' ;tf!.i!| 

■ J',, ■ • \Cr) -\: ■■■■ . ' ■■ .\irr.in>t« 

This example also makes some assumptions about the placement of descriptors in the GDT. ^gsts^ 
3-6 illustrates these assumptions: 

Tht memory manager frequently needs to create temporary descriptors for such purposes as reading 
and updating the boundary tags and link fields. For its own convenience, the memory manager 
reserves GDT slots for these temporary descriptors. This example identifies the slots as SLOT_A, 
SLOT_B, and SLOT_C. . . , , . . . ^ r 

•"" i^dfiifeflr slots in the GDT <Mflaia4fi^=*iiescripfors m ^^^mMm fSf Me task. TftW *ialy, |*v*eft a 
selector for one task descnj^d^ dAPdidditiiai i^Mll^^ foi"other des^^^ib 

for the same task. •'• ' ' ' - ■ ' ' ' ' • 'rn i 
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There are two ways to reserve slots in a descriptor table: 



I . Code absolute selector values in the progrsan and use the Builfler's RESERVE statement to prevent, 
the Builder from allocating other fleseriptors to those slots. Tiis is; thg jiiPlhod used in this example ' 

Use EXTERNALS to dummy segments coded in an ASM286 module, and allow the Builder to 
assign slots for the descriptors of the dummy segments. The Builder resolves the EXTERNALS. 



PL/M-286 Code 



This example separates space-management functions from descriptor-management functions. The space- 
management procedures are DELINK, FIND_FIRST_FIT, and RETURN_SPACE. The public 
procedures ALLOCATE and FREE^EG call on POINT_AT and NULLIFY to manipulate descrip- 
tors for allocated segmente..Cffi&aL.l3fcktpter 2 for definitions of POINliT ^nd NULLIFY.) ; 



rhc PL/M-286 built-ins Ui^itojrtinipulate system structures in th 

lELECTDRfOF (poWfiw) 
'ET$SEGMENT$LIMIT ( sele&or) 



ftpfe include 



The external procedure GETSSEGMENTSBASE extracts the segment base address from the speei-J 

fied descriptor. 

Wh^^t;^p procedure FIND_FIRST_FIT finds an available space that is much larger than requested^ 



space list. Figure 3-7 illustrates tll@fi%ie»M^ii^litn.ivSi]siMie?^ace. 



iressed portion inthe-fi^ee^ 
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Figure 3-6. Example GDT Layout 



When returning an unneeded segment to the available list, the procedure RETURN_SPACE checks 
the boundary tags of both the lower and higher adjacent segments to see whether there is another free 
segment with which to combine. Four cases are possible, as illustrated in figure 3-8 at the end of this 
ehapler. Table 3-1 summarizes the actions taken in each of the four cases, iu^j-, •• ' ' 

' I ■ ■ .1 I ifrjK'l^ ^ r,7 >:nsrr!'^M a'slubofTs jrf) 1o yqo: -Mi • ■ ■• i- -n 

See figure 3-9 at the end of this cfeaptef f*"tM'Pl;fM48®"S8iS example cif a 

memory manager. 

Protection Structure 

Where in the two-dimensional grid of protection offered by the iAPX 286 should the memory- 
tnahagement nlbduleSW There iipfe t^'i{pi»Mfes'**WMW*wft^!*18ife«fS|« ' '"'"''''^ • 

1. The module can be structured as privileged procedures that execute as part of every task that 
calls them. , .- .-.iv/ , : ,. . 

. ' 1... • ■ . -J ot; 3zo!i: gniPi;. i'vj ■ .;■ • 

2. The module can execute as a separate- task 
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Figure 3-7. Splitting an Availabie Biocl( of IMemory 



GLOBAL PROCEDURES , ■ , ^ , luod 3 

Placing the module's segmem^^lfp^1h%ii{i^iFd9iMiaif4^^^ ^<$ystem to sbsa'e'the lMMie 
yet requires only one copy of the module's segmeate to be present in memory. This approach allows for 
fastest communication betwe^ tj^ a^piicatioa aii^ iS^i m^ory nstanager. 

The procedures of the memory manager synchronize with the calling procedure (that is to say, the 
calling procedure waits until the memory-management procedure returns). However, more than one 
task can be executing the memory-management procedures at one time. This can be an advantage (as 
when there are multiple CPUs and the requests are for different regions of the memory space), but it 
requires synchronization of changes to space-management data structures (not shown in this example). 

Segments containing proc$^iiHes and data structures internal to this most critical operating-system 
module should have the greatest protection possible. Because none of these procedures and data struc- 
tures are PUBLIC, no other modules can gain knowledge of the locations of data and procedures. This 
by itself, however, does not constitute positive protection from accidental or intentional snooping or 
destruction. The segments containing these procedures and data should have privilege level (PL 0) 
so that the processor can prevent any access from less tfwtedjjrocedures. 
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Table 3-1. Actions for Combining Segments 



Action 


Case 


Case 1 


Case 2 


Case 3 


LO Ml 

Free Free , 


1 M UI 




uo ni 

Used Usacl 


CURFl_AVLBL= 


IJO 

START"' 


'START-'--' ■ 


^ T 1 Ills 


Thie 

1 nis 
Base 


CyRR^LINK.PRK)R = 


— 




Hi 

LINK.PRIOR 




CURR_LINK.NDa= 








firstJvVLbl 


UbLINK nl 


Yes 


NO 


NO 


Kin 

NO I. 


FIRST_AVLBL = 
CURR_AVLBL? 


No 


No 


No 


Yes 


PRIOR FREE 
LINK.NEXT= 
CURR_AVLBL? 


No 


No 

. , fl jilr. .ii rf.fl 'IK 


Yes 

gift ;t' A- ,i,.^n^vi , 


No 


mxr FREE 
LINK.NEXT= 
XURR_AVLeL? 


No 


• . No . ^ -; i 


nq nbtTaTToti aiir i 
r r -if-'^it^' --irtJ .f.r : 
-.-lYas! 


Yes 



The PUBLIC interface procedures ALLOCATE and FREE_SEG should execute at PL to access 
the internal data structures and procedures, which are also at PL 0. ALLOCATE and FREEJSEG 
should have gates at PL 3, however, so that even least trusted application procedures can get the space 
they need for such purposes as dynamic data structures. 



SEPARATE TASK 



Another possible structure, not exemplified here, is to treat the memory-management module as a 
separate task. The iAPX 286 features for isolation of tasks provide the needed protection for the criti- 
cal memory-management structures and procedures. Within the memory-management task, privilege 
levels can be used to isolate the various internal procedures and data structures from one another. The 
memory-manager task can use a message passing mechanism such as that shown in Chapter S to receive 
requests and to pass segments to the requesting task. 

With the memory-manager executing as a separate task, serialization of requests for space is automatic, 
thereby eliminating the need for synchronization when modifying space-management structures. The 
separate-task approach is also advantageous when there is a need to have the requesting task wait until 
sufficient memory becomes available to fuUfil a request. While one task is waiting, the memory manager 
can continue to service requests from other tasks. 



121960-001 



REAL MEMORY MANAGEMENT 



ADVANCED MEMORY MANAGEMENT 

In actual applications, the memory-management module may need to deal with such topics as 

• Different kinds of memory. The ALLOCATE procedure needs a parambter to specify (for example) 

versiKitast mem6?^7an81!^h fype^^ttieffiB^ nicdsPfts Wf frte-space list. 

Multiprocessing. When multiple processors share some, but not all, of the available memory, the 
memory management module mus,t know what memory addresses each processor can access, 
i- ALLOCATE must provide memorjf thatiiajccessible to the processor that is running the jcaUing 
i task. You need to partitiofi memoir into areas so that all the address in a given area satisfy n 
' cornnl^ accessibility constraint. (Tne criteria for pakitioning^ may alio include memofy tJ^leS a^ 
mentioned previously.) Each area needs its own free-space list. 

• Dynamic deletion of memory. When a memory parity error occurs, the need for continued system 
I operation inay require; de/kst^ihe i ffected block of memory from the 'available-space lists, thai 

it cannot cause ntt>re trouble. 

• Fixed-location segments. Often certain addresses of memory have specific uses, for example, video 
j refresh buffers, and communication blocks for intelligent peripheral controllers. The memory manager 

must be aware of these areas and not use them for other purposes. Its interfaces must include the 
means for a task to request a specif^ special jpurposekrea. 

Compaction. It can happen that no single free memory space is large enough to satisfy an 
ALLOCATE request, even though there is enough total free memory. Some memory-management 
subsystems call on a compaction algorithm in such cases. Whether implementation of a compaction 
algorithm is worthwhile depends primarily on the pattern of memory usage in a given application. 
' In many applications, this situation arises only when memory is nearly full anyway; compaction in 
this case merely delays the inevitable by an insignificant time. If you do implement compaction, 
i you may choose to associate with ieach allocated segment a pointer that helps the comftel^ion 
'•—algorithm find the descriptors for that sclent. -WitJfa-memory-management scheme such as-tbat 
exemplified here, the boundary tags are the most convenient container for descriptor pointere. With 
descriptor pointers in place, the compaction algorithm need only follow the available-space lists to 
discover all the opportunities for compaction. .1 
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REAL MEMORy NtlUlil@@iilfr 



PL/M-286 COMPILER 960-501 date PAGE 



system-ID PL/M-286 DEBUG Vx.y COMPILATION OF MODULE MEMORY 
OBJECT MODULE PLACED IN : F 1 : MEMORY . OB J 

COMPILER INVOKED BY: : F3 : PLM286 . 86 : FlrMEMORY. PLM CODE DEBUG 



$ PAGEWIDTH(71) TITLE (' 960-501 ' ) INCLUDE ( :F1;N0CS0B. PLM) 

5 NOLIST 

1 MEMORY: DO; 

/********»**»*»******»**********»»*»****-»**»»»»»*»»**»»* / 

/* Externals. */ 

2 1 point_at: procedure (slot, rights, phys_addr_ptr , limit) 

extbrmal; 

3 2 declare slot selector, rights byte, ' ' 

PHYS_ADKl_PTR PfflNTER,' LIMIT WORD; 

4 2 END POINT_AT; 

5 1 NULLIFY: PR<X:BDOREV(S)MS)^'%S9^Rlfi!iL; 

6 2 DECLARE «LOT SELECTORf " 

7 2 END NULLIFY; 

8 1 GETSEGMENTBflSE: PROCEDURE (SEL, BASE_ADDR_PTR) EXTERNAL; 

9 2 DECLARE SEL SELECTOR, BASE_ADDR PTR POINTER; 

10 2 END GETSEGMENTBS-S&; -I-- -~ 

T : no.') f .: 

/****** ***»**jtmMBJi>*iwiiwiMK)Bi*»ii.imh)ai****»***** / 
/* ' Slpab6-m2ili%4^4hr dSfffritions. */ 

11 1 DECLARE PARAGRAPH LITERALLY '16'; 

/* To run under SIM286, all segments must have a base 
address equal to zero mod PARAGRAPH. This is not 
required when running on iAPX 286 hardware. */ 

12 1 DECLARE MEM LINK LITEmCIfr; -.. ' i 

'PADDING (8) BYTE, ii-LV-- J J " 

START DWORD, 
HI_TAG WORD, 
LO_TAG WORD, 
PRIOR DWORD, 

NEXT DWCSlDv - / 

SIZE DWORD'; 
/* Base address of link descriptor is eiiH^fys PARAGRAPH 
less than address of PRIOR field. Address of PRIOR 
field is always mod PARAGRAPH. PRIOR, NEXT, and 
SIZE fields always point to a PRIOR - PARAGRAPH 
address. */ 

13 1 DECLAS'E' TXGS"_S'iyB ■ LITERALLY '4'; ' 

/* The space used by both tag words */ 

14 1 DECLARE LINK_LIMIT LITERALLY '27'; 

/* Limit used to construct descriptors for MEM_LINK */ 

15 1 DECLASE BLOCK_MODULUS LITERALLY '32'; 

/* All memory blocks are an integral multiple of 

BLOCK_M0DULDS in length. */ 



Figurer3#.9^i«(t« for Memory-Management Example 
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16 


1 


DECLARE NnLL_PHyS ADDR LITERALLY ,';0 ' -r ! 


17 
18 


1 
1 


DECLARE USED LITERALLY '1', 
FREE LITERALLY '0'; 
/* Values of boundary tags */ 

i. ••• ■•i»-8»«MauTJT (J', rn-.v- <v. ■ 
DECURE OK LITGRALLy '0', 

FAILED LITERALLY '8000H'; 
/* Values of exception codes */ 


.19 


1 


DECLARE DWRIGHTS ■ • <D-I-T«RALLY '92H' /* For manipulating 
space-management data structures, this module 
needs these rights parameters: Present, DPL=0, 
•, ^■^4^^ta. segment, grow up, writ-aSjiev- */ ; 

******* ****** **^iHM^** *-**,* *************** ***************y 

/* Space-management data structures. */ 


20 


1 


DECLARE (FIRST_AVLBL,LAST_AVLBL,CURR_AVLBL)DWORD PUBLIC; 
/* Physical-address pointers to chain of available 
space. These always point to PRIOR - PARAGRAPH to 
: ^yoi4':(S^qiii^d^iq9,'J|S{|«;..^cti3^jSses €or MEM_LINKs. */ 


21 


1 


DECLARE SLOT A SELECTOR PUBLIC, 

WSLOT A WORD AT (?SLOT A) INITIAL (38H), /* 7 */ 
SLOT B SELECTOR PUBLIC, 

WSLOT B WORD AT (@SLOT B) INITIAL (40H), /* 8 */ 
SLOT C SELECTOR PUBLIC, 

WSLQ?" <i W<»03AfflT(gS£,0!I! C-X' INITIAL (48H); /* 9 */ 
/* "Sc»a*oh*. Slots foTf addressing MEM_LINKS. */ 

/* Be sure to reserve these slots with the Builder */ 






/*******************************************************/ 

/* Round a size parameter upwards to next greater */ 
/* or equal (N * BLOCK_MODULUS ) - TAGS_SIZE for some N */ 

RO0ND_SIZE: PROCEDURE (A_PTR) PUBLIC JS^HWANT ; 


22 


1 


23 


2 


DECLARE A PTR POINTER, r ^ , . 
ADDR BASED A_PTR DWORD; 


24 


2 


ADDR = BLOCK_MODULUS 

* (■< (AODR *i vffAQS: SMiS l» vl )n;/ .BLOCK MODULUS) + 1) 
- TAGS^S IZB"!! ' '-rr ;r,' :■>; ' f bi 


25 


2 


END ROUND SIZE; - - 

y**********^^:*********^********************************** y 

/* Delink from available space list. */ 


26 


1 


DELINK: PROCEDURE (THIS_SEL) REENTRANT; 


27 


2 


DECLARE THIS SEL SELECTOR, 

THIS_LINK BASED THIS_SEL STRUCTURE (MEM_LINK); 


28 


2 


DECLARE PRIOR_LINK BASED SLOT_C STRUCTURE (MEM_LINK) , 



Figure 3%^ 'f&^ «PiAiioil^iffMadb«ra«if EMi|il« ^Cibnt'd.) 
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29 


2 


IF THIS LINK. PRIOR = NULL PHYS ADDR 








/* This is the beginning of the list. */ 




30 


2 


THEN FIRST AVIiBIc «j "f^Jilf^RINK. NEXT ; 




31 


2 


ELSE DO r Update link from pr ior segment , */ 




32 


3 


CALL POINT_AT (S^i^ IBV' DWRIGHTS, r 








^^THIS LINK,PRI0Rv LINK_LIMIT) ; 




33 


3 


PRIOR LINK. NEXT = THIS LINK. NEXT; 




34 


3 


END; 




35 


2 


IF THIS_LINK-.NE^ NULL_PH YS_ADDR 








/ inis ±s une ena ox une xiati* / 




36 


2 


THEN LAST' AVLSC THIS LINK. PRIOR; 




37 


2 


ELSE DO; /^-'Update link frptn next segment. */ 




3 a 


3 


CALL POINT ATlSLOT t- » DWKHjHIo, 








@THIS LINK. NEXT, LINK LIMIT); 




39 


3 


NEXT_LINK^PRIiOR 5!HIS_LINK. PRIOR ; 






3 


END ; 




41 


2 


END DELINK; 
















/d> d>d>^A^.bAA^^iAi^AA lA^A A^i* A AAA AAA AAA A A A A A A A A A AAAAA4AAA44^4r<fr'#J 


/ 


42 


1 


FIND FIRST FIT: PROCEDURE (SIZE, BASE_ADDR_PTR) 








WORD REENTRANT; 




43 


2 


DECLARE SIZE WORD, 








BASE ADDR PTR POINTER, 








BAS1_ADDR :,m:^& MtEJIlQtiy?<1^uW<0RO; 




44 


2 


DECLARE CORR LINK BASED SLOT A STRUCTURE (MEM LINK), 








IMYS_SIZE DWORD, 








faiitj Uirr UWUKU, 








/* Boundary tag iteiR3:*/f , 








BOUND ADDR DWORD, 








BOUND tllD^ .BASBD.SLQT'B SfgaQTOBE (MEM LINK), 








BOHND_HI BBSEE>i SIiOT_B 'STRUCTURE (MEM_LINK) ; 




45 


2 


DECLARE TOP_LOOP LABEL; 




46 


2 


PHYS SIZE = SIZE; ii 




47 


2 


CALL ROUND S I ZE ( ?PH YS_S I ZE ) ; 




48 


2 


CALL POINT_AT (SLOTjA, DWRtGHTfl'.VJ A JciLlOB 








§CURR AVLBL, ' LISfK-LIMIT) ; 




49 


2 


TOP LOOP: 








IF SLOT A = SELECTORSOF (NIL) /* Check for end of list * 


/ 


50 


2 


THEN DO; 




3 1 


J 


T T? PTOCTi ^\JT nr — Mfir r duvq anno 

ir C IKoX AVLjDLj — NUbLj fniD AUUK 








/* The. I4«ti!.ist:eiip*)ir7i5if/a vrncno - 




52 


3 


THEHvJ R*T08Hi ■ f aiSEtil - 




53 


3 


end; . 




54 


2 


ELSE: CALL POINT" AT(SLOT A, DWRIGHTS, 








@FIRST_AVLBL, LINK_LIMIT); 








/* Continue frem beg inning ^10^= list > 




55 


2 


IF CURR_LINK.SIZE < PBYgTS'IZE 








THEN /* This segment is too small, so... */ 





Figure 3-9. Code «ec M9inairiHManag«lnMt!£K0ni^ 
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56 


2 


DO; /* Look at next free segment in the list. */ 


57 


3 


CALL POINT AT (SLOT A, DWRIGHTS, 






•'l#CtJtSS_f.*M«vNEXT, L1NK_LIMIT); 


c o 

DO 


3 


IF CURR^AVLBL = CTOlK_I.1(fif wMESCT 






/* Have searched entire list Without a hit, */ 


59 


3 


THEN DO; 


60 


4 


CALL NULLIFY(SLOT A); 


ox 


4 


RETURN FAILED; ' 


62 




END; 1 • 


63 


3 


GOTO TOP_LOOP; 


fiA 


■a 
J 


END; /* Segment too smaEt'tiii */ 


O D 




SIZE DIFF = CURR LINK. SIZB'.ji PHYS SIZE; 






/* Always a multiple of aiiOCK_MODULUS */ 


66 


2 


IF SIZE DIFF = ' '■ 


67 


2 


THEN 'BO'}- •■/* 'TWi^a ■'fii^.eBf''#s<'J» -^ILvse fit . */ 


C D 

D a 




C08R AVLBL * CURS L1!3K. NEXT ; 


c a 


3 


CALL DELINK (SLOT_A) ; 






/* Set lower boundary tag */ 


1 fX 


3 


CORR XtM^tlS USED; 






/* Set t^f^r boundary tag */ 


71 


3 


CALL GET$SEGMENTSBASE (SLOT A, @BO0ND ADDR); 


72 


3 


BASE ADDR = BOUND ADDR; ~ ~ 


73 


3 


BOUND ADDR = BOUND ADDR + C0RB 'LlWK. SiaE + TAGS SIZE; 


74 


3 


CALL POINT AT{SLOT B^DWHTGHTS /ABOUND ADDR, LINK LIMIT); 


75 


3 


BOUND HI. HI TAG =USED; 


/D 




CALL NULLIFY (SLOT A); CALL NULLIFY (SLOT B) ; 


1 O 

to 


3 


BASE ADDR = BASE iS&OR * PARAGI^PH ; ~ 






RETURN OK; ~' 






END; /* Close fit. */ 


a 1 


z 


ELSE DO; /* It will fit here with room to spare. */ 




^ 


CALL GET$SEGMENT$BASE (SLOT A, I3CURR AVLBL) ; 






/* Set boundary tag at end of new segment. */ 


83 


3 


BOUND ADDR = CURR AVLBL + CURR LINK. SIZE + TAGS SIZE; 


84 


3 


CALL POINT AT(SLOT B, DWRIGHTS , @BOUND ADDR, LINK LIMIT); 


03 


■5 

.3 


BODND_^HI.HI_TAG = USBOS^ix- ' : 






/* Calculate startl«§''aaat6ss-of 'the new segment. */ 


86 


3 


BOUND ADDR = CURR AVLBL + SIZE DIFF; 


87 


3 


BASE_ADDR = BOUND_ADDR + PARAGRAPH; 






/* Set the boundary fields between the 2 segments. */ 


88 


3 


CALL POINT AT(SLOT B , DWR I GHTS , @B©OND ftOOR,LINK LIMIT); 


89 


3 


BOUND MID. START = CURR AVLBL; - 


90 


3 


BOUND MID. HI TAG = FREE; 


91 


3 


BOUND MID. L0""TSG '*"0S1!D;' ' " 






/* Change size of available segment. 






considering the 2 boundary tag words. */ 


92 


3 


CURR LINK. SIZE = SIZE DIFF - TAGS SIZE; 


93 


3 


CALL NULLIFY(SLO«P A) rC»L 1lira,EIPY{B.LOT B) ; 


95 


3 


RETURN OK; 


96 


3 


END'J-- */* ' R<Hami %0'^*il8*%."*/ 


97 


2 


END FIND FIRST FIT-; ' - - < 






$EJECT 



Figure »«..!Gode'«wM«RHNi^MaiH«#in«mtexamp^^ 
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/* Place a segment into the available space list. */ 

98 1 RETURN SPACE: PROCEDURE (FREE SEG) REENTRANT; 

~ ~ , " • f 

99 2 DECLARE FREE SEG ,- SELECTOR, ■ ■ 

-FRlE[];b'IilK " pkS^ft ^RElE_SBf' 'HR6eTURE (MEM_LINK) ; 

100 2 DECLARE CURR_LINK BASED SLOT_A STRUCTURE (MEM_LI8K) , • ' 

NEIBR_ADDR DWORD, 

NEIBR_LINK BASED SLOT_B STRUCTURE (MEM_LINK) , 
FREE_BASE DWORD, - 

FREE_SIZE DWORD, '-'^ 

HI_SIZE , , DWORD, '] ''''. 

NCASE ' BYTE, ' 

HI_USED LITERALLY ' 01H ' , 
LO_USED LITERALLY '02H'; - "> 

101 2 CALL GET$SEGMENT$BASE (FREE_SEG, @ FREE_B ASE ) ; 

102 2 FREE_BASE = FREE_BASE - PARAGRAPH; /* point to tags */ 

103 2 FREE_SIZE = GET$S EGMENT$L I MIT (FREB_S«G) ; 

104 2 FREE_SIZE = FREE_SIZE + 1; " ' ■ . ' f 

105 2 CALL ROUND_SIZE (eFREE_SIZE) ; ' ' ■-' ^ 

/* Determine which case. */ 

106 2 NCASE =0; ! 

/* Check higher neighbor. */ 

107 2 NEIBR_ADDR = FREE_BASE + FREE_SIZE + TAGS_SIZE; 

108 2 CALL POINT_AT ( SLOT_B , DWR I GHTS , I? NE IBR_ADDR , LI N K_L I M IT ) ; 

109 2 IF NEIBR_LINK,. LO_TAG = USED THEN NCASE=NCASE OR HI_USED; 

111 2 ELSE HI_SIZe' = NEIBR_LINK. Sf*^;' /*»'#iiVe */ 

/* Check lower neighbor. */ ''P ^J'-' "^^ 

112 2 NEIBR_ADDR = FREE_BASE; 

113 2 CALL POINT_AT (SLOTB, DWRIGHTS ,?NEIBR_ADDR,LINK_LIMIT) ; 

114 2 IF NEIBR_LINK. HI_TAG=USED THEN NCASE=NCASE OR LO_USED; 

/* Which segment should become the new current one? */ 

116 2 IF (NCASE AUB .E^_CSED) <>0 ;UMa 

117 2 THEN CDBS_A\aVL •='■ t'REE_BASE; ftfw Tii¥%hboE used */ 

118 2 ELSE CDRR_AW:,BL = NEIBR_LINK. START; /* low free */ 

119 2 CALL POINT_AT(SLOT_A,DWRIGHTS,@CURR_AVLBL,LINK_LIM1T); 

/* Calculate size of new segment. */ 

120 2 IF (NCASE AND LO_USED) = LO_USED /* if low neibr used */ 

121 2 THEN CURR_LINK. SIZE = 0; 

122 2 ELSE /* already contains size of low neighbor */ 

CURR WHK. SI zi = CTRR JfJllK. S.IZ,E. .+ -TSC5S- SIZE; 

123 2 IF (NCXSir'l^M ffrOSEOf ^-tfi tfife' '' J-"^ 

/* if high neighbor free *7 

124 2 THEN CURR_LINK. SIZE = C URR_L I N K . S I Z E+H I_S I ZE +TAGS_S 12B' ; 

125 2 CURR_LINK. SIZE = CURR_LI NK . S I ZE + FREE_SIZE; 

/* Set next and prior links in new segment. */ 

126 2 IF NCASE = 3 /* neither neighbor free */ 

127 2 THEN DO; /* insert at head of available list */ 

128 3 CURR_LINK. PRIOR = NULL_PHYS_ADDR; 

129 3 CURR_LINK.NEXT = FIRST_AVLBL; 

130 3 END; 



l^igur^ ^^'XSadeim mmmi^ H mm^it th^msShttfie^imuted.) 



3-19 



121960.001 



my 



REAL MEMORY MANAGEMENT 



PE/M-Z86 COMPILER 969-391 ^ate ,. PAGE 6. 

131 2 . ELSE IF (NCftSS AND HI_USED) <> HI_OSED 

/* if high neighbor free */ 

132 2 THEN DO; /* Dispose with high neighbor's links. */ 

/* Make selector for high neighbor. */ 

133 3 NEIBR_ADDIl = -FREB B*SE + FREE_SIZE + TAGS SIZE; 

134 3 i CALL POINT_AT(SL6f'_B,0WRIGHTS,@NEIBR_ADDR,LINK_LIMlT); 

135 3 IF NCASE = /* both neigbt>df-f , f"^®® */ 

THEN /* remove one from available list. */ 

136 3 CALL DELINK (SLOT_B); 

137 3 ELSE /* Must be case 2. */ 

DO /* Transfer links to new current. */; 

138 4 CDRR_LINK. PRIOR = NEIBR LINK. PRIOR; 

139 4 CURR_LINK.NEXT = NEIBR~LINK. NEXT; 

140 4 END; 

141 3 END; /* disposing with high neig||ibor's links. */ 

142 2 IF (NCASE AND LO_USED) = L0_USEj3' 

/* if low neighbor used. */ 

143 2 ...THEN DO; /* Fix up links in prior and next segments.,?/ 

144 3 - I CURR_LINK. PRIOR = NULL_PHYS_ADDR 

, .T^lfe/^- therie ia. jfp prior */ , 

145 3 FraST_AVL6L » CbRR_AVLBL; 

146 3 ELSE DO; /* fix up prior */ 

147 4 NEIBR_ADDR = CURR_LINK. PRIOR ; 

148 4 CALL POINT_AT (SLOT_B, DWRIGHTS, @NEIBR_ADDR, 

LINK_LIMIT); 

149 4 NEIBR_LINK.NEXT = CURR_AVLBL; 

150 . 4 ..^ixmnv," -T'lOiHw , 

151 3 lFCORR_tlNK.»IEXt = NULL_PHYS_ADDR 

THEN /* there is no next */ . 

152 3 LAST_AVLBL = CURR_AVLBL; . . 

153 3 ELSE DO; /* fix up next */ 

154 4 NEIBR_ADDR = CURR_L I N K . NEXT ; 

155 4 CALL POINT_AT (SLOT_B, DWRIGHTS, @NEIBR_ADDR, 

LINK_LIMIT) ; 

156 4 ,tJEIBR_LISS.PRIOR = CURR_AVLBL; 

157 4 END; 9v>,^ i ■ , ^- ■ 

158 ■ 3 ,4^; ,,/!.* Kl,xii>9,«0|>^ks> ,„j . „ 

/f-Bet tag words */ • ' i" 

159 2 CURR_LINK.LO_TAG = FREE; 

/* Set START field in new current segmeai;. */ 

160 2 NEIBR_ADDR = CURR_AVLBL + CURR_^LINK. Sl2B > TAGS_SIZE; 

161 2 CALL POINT_AT (SLOT_B, DWRIGHTS , 9NE,IB|! Mg|b>LINK_LM 

162 2 NEIBR_LINK. START = CURR_AVL¥l;' , ■ "tl^"; ' 

163 2 NEIBR_LINK.HI_TAG = FREE; 

164 2 CALL NULI^KX (SLOT A); CALIj;'^3^i!5r^!:'^b<^^B) ; 



166 2 END ,^TORJS_S PACE; 
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167 


1 


ALLOCATE: PROCEDURE (SLOT, RIGHTS, SIZE, EXCEP PTR) 






PUBLIC REENTRANT; 


168 


2 


DECLARE SLOT SELECTOR, 






RIGHTS B!TE , 






SIZE WORD, 






EXCEP PTR POINTER, 






EXCEP BASED EXCEP_PTR WORD? 


169 


2 


DECLARE BASE ADDR DWORD; 


178 


2 


IF OK <> FIND FIRST FIT (SIZE, @BASE ADDR) 


171 


2 


THEN DO; ~ ~ ~ 


172 


3 




173 


3 


RETURN; 


174 


3 


END; 


175 


2 


CALL POINT AT (SLOT, RIGHTS, 9BASE ADDR, SIZE-1); 


176 


2 


EXCEP = OK; 


177 


2 


END ALLOCATE; 






^* * * Itt^iiUcifk-kit'kltli'kltlfklt * * *A!4rA4tilt*A*flt4r4rA*4t*it4cricik]lr4rifeikA*1lritr*AAilk y 


178 


1 


FREE_SEG: PROCEDURE (SLOT, EXCEP PTR) PUBLIC REENTRANT; 


179 


2 


DECLARE SLOT SELECTOR, 






EXCEP_PTR PO INTER , 








180 


2 


CALL RETURN SPACE (SLOT); 


181 


2 


CALL NULLIFY (SLOT); 


182 


2 


EXCEP = OK; 


183 


2 


END FREE_SEG; 








184 


1 


END MEMORY; 



Figure 3-9. Code for Memory-Management Example (Cont'd.) 
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CHAPTER 4 
TASK MANAGiMENT 



The primary responsibility of an operating system is to allocate the processor tor the executing tasks so 
that each tasic makes progress consistent with its role in the application. This chapter examines how 
the task-oriented features of the iAPX 286 hardware apply to conventional task-management concepts. 



HARDWARE TASK-MANAGEMENT FEATURES 

The operating system's responsibility for managing a multitasking sj^t^m is reduced by iAPX 286 
features for saving and restoring task state and switching betweei tas^- i 

~T 

storing Task State 

The state of a task (from the processor's point of view) is the contents of the registers used by that 
task. The architecture of the iAPX 286 defines a special type of segment, the task state segment (TSS), 
for storing the 80286-related state of a task. Multitasking operating systems on any processor need to 
store similar information. The iAfiX 286.-requires merely that a specific format be used so that the 
CPU can store and restore task state automatically, figure 4-1 illustrates a TSjS and related hardware 
structures. *a i 

The processor keeps the location of the TSS of the currently executing task in the task register. The 
task register has two parts: ~5 

• The "visible" portion, which a task can access. This part contains a selector to the descriptor (in 
the GDT) for the current TSS. 

• The "invisible" portion, which ta^ks do not cqotrpl. When the contents of the visible portion are 
changed, the processor loads the invidMis pQrn>4 with the base and limit values from the TSS 
descriptor indexed by the selector in the visiUe^drtion. 

There are two ways to change the task register: 

• By one of the task switching operations described later in this section. 

• By the LTR instruction. LTR is used to give the task register its initial value during system initial- 
ization. Only privilege-level (PL-0) procedures can px&c^te LT?.. . 

Because TSSs correspond one-to-one with tasks, the selector of a TSS uniquely identifies a task. The 
STR instruction reads the task register into a selector. Operating-system procedures can use STR to 
identify the calling task. The btult-W'i^«r&ible TASKSREGISTER gives PL/M-286 programs access 
to the task register. ■ 

The items in the TSS fall into four classes: 

• Back link. Contains a selector to tlie'-"ISS of the' b^Bng (or interrupted) task (if any). 

• LDT selector. Contains a selector to this task's LDT. 
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Figure 4-1. Taik State S(^gment aiicf Register 



• Processor registers and flags. Used to store the processor state of the task. Note in particular the 
NT flag, which indicates when the BACK LINK contains a valid selector. 



• Initial stacks. Contain the initial SS and SP values to be used when a CALL transfers control to 
any of the higher PLs (0, 1, or 2). No stack pointer is needed in the TSS for the PL-3 stack because 
that stack is either the current stack (pointed to by the SS:SP fields) or is locatable via the chain 
of stack pointers in higher-level stacks. 
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The processor updates only the back link, the registers, and the flags as part of a task switching opera- 
tion. The processor merely reads the initial stack fields (during interlevel CALLs) and the LDT selec- 
tor (during a task switch). The operating system is responsible for initializing the stack and LDT fields. 
It must also update the LDT sekc;tor,^fiMr«;ch?!ng^ 

I'-.rij .Aih'. 'jld.-.lic-vt; ns; jfSi.prrsb .i i-l -^b'^-j aqvj -nil - c » 

• : . -■ . OJ d-. <: -qi.i . tJi' --.G r-jf!' J^si ysut' .. vji.i-- 

Switching Tasks ' 

Since a multitasking system typically has more tasks than'it't^'^fwsessctfs to execute those tasks, 
there must be some provision for causing a processor to cease executing one task and begin executing 
another. The 80286 has several such mechanisms, each appropriate to different situations. All use 

ordinary JMP, CALL, INT, or IRET instructions. The destination operand determines whether a task 
switch occurs. Table 4-1 summarizes the operations and operands that cause switching of tasks. 

In PL/M-286, an indirect CALL statement to the selector of a TSS descriptor or task gate causes 
generation of an intertask CALL instruction. The WAITSFORSINTERRUPT built-in procedure 
generates an IRET instruction. ' 

The operand of a CALL or JMP instruction is a pointer containing both selector and offset parts; in 
this case, the offset is not used, however. The selector portion may refer either to the descriptor of a 
TSS or to a task gate for a TSS. The result is the same in either case. The difference lies in the 
protection of access to the TSS. TSS descriptors, which may reside only in the GDT, normally have 
P?L set to zero to prevent unauthorized task switching by procedures outside the operating system. 
Task gates may reside in any descriptor table, giving task switching abi^^i^io procedures that have 
access to the gate. A task gate in an LDT gives task switching power aaly to tlai tDTs task.' A task 
gate in the IDT gives task switching fknMer to inteoii^^fhis reduces operating-system involvement in 
interrupt handling, and thereby reduces the time needed to respond to interrupts. 

The operating system normally uses a JMP instruction to a TSS descriptor to cause a task switch. A 
CALL instruction to a task gate in an LDT is useful for implementing coroutines. 

The IRET instruction exits from a nested task that is invoked by a CALL as well as from one invoked 

by an interrupt. (You cannot use the RET instruction to exit from a CALLed task: RET does not 
perform a task switch.) The NT (nested task) flag controls the function of the IRET instruction. When 
a CALL (or interrupt) causes a task switch, the processor sets the NT flag as the new task begins and 
fills the back-link of the new TSS with the selector of the calling task's TSS. When the NT flag is set, 
the IRET instruction causes a task switch to the task whose TSS selector is stored in the back-Unk. 
The new task must be marked as busy (type code = 3); otherwise an exception occurs. ■ .' 

-J 

y ' ' Table 4-1. Task Switching Operations 



Operation 


■-j&f'rni^.', 

Descriptor 

^ Referenced 

ji.- noil:] ,i 


Descriptor 
Table 


CALL, jiwiP, IRET ' ' - 




GDT 


CALL, JMP 

: i'. 


task gate 


GDT, LDT 


INT instruction, 
external interrupt, 
exception 


■UO ■O' MP.I-'J. :ji:".T;,.n .b lii . 

■ ■ 'tSsk gSte' ' ' 

:,:':;vj.,ir, j,r, ' • f': 


C'l;-:.,.-.: • IDT 
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If the processer, while executing an IRET instruction^ finds the NT flag not set, this indicates a return 
to an interrupted proeedui'e in the same task. R^belslAB^iiaiii iMtiiMk ito mtermpt.pTOceiirASiii i 

■ I - ' . L,^iM.->. M: 11,', ^lljj.-l.;,' -A - ■■ ■ ^JTllin^fij - I't ' ,1,1 Kj.-- .it) 'Cj 

For CALL and JMP instructidfts;^cesi oPi task Switch opei^lfdnUeit)^ri<is' oil the type field WtW^ 

TSS descriptor. If the type code is 1, denoting an available task, then the task switch proceeds. If the 
type code is 3, denoting a busy task, then an attempt to switch to the task causes an exception. A task 
is busy under either of these conditions: ■ .' -. wS 

•.- The ta^ is the currently exeoutingtta8ki ■ '• = • r - • > v 

• The task is on the chain of TSS back-links from the currently executing task. This prevents recur- 
sion of task invocations. A task should be restarted only by the the task that interrupts it or by the 
6i$erating system aftef the task has been removed from the back-link chain. 

If the target task is not busy, the processor takes these steps in executing a task switch: 

■ ■ "i/ •/; oifT i<r.:K-t.nU:r J i.' 

• Saves all registers in current TSS . : . , 

• Loads TR with new TSS descriptor 

• ^ l^ds all registers and flags from new TSS (including^ jI,DT re|;ister) ' 

•f IPiswitfchis dtie to GALi;-'<®rkftBiiTapt>rrsBts^1W'tfMg!^ new TSS to poiwt l6 

previous TSS > . ; ■ 

• If s>yitch is due to JMP or IRET, changes the old task's descriptor type code to one, indicating that 
^ ^l^lsnq4Qnger t(ftsy . i.! i 

•I R^uMoies new task where it left off (i.e., CS:IP from new TSS) 

Note that you cannot pass parameters by an intertask CALL. It is possible to share data between tasks, 
ho#©vef. Chapter 5 takes t^itMg^ subject. - mM!. , !. !, JiV i , . , u -..; - 



POLE OF QPERATINf:^ SYSTEM IN TASK MANAGEMENT ^ 

Task switching without operating-system involvement is possible (though not necessarily advisable) in 
static systems. Consider the following two application-driven scheduling strategies for static systems: 

1 . A fixed sequraice of ta^ks/is de&aediamd e^e^k'tmSgiOii^^ ready to retei|i;^h tl».ptmms<Xjm^' 
tarily calls or jumps to the next task in sequence. Barring any errors, each task gets a share of 

processor time. 

2. All tasks in the system service external events. The interrupt -mechanism of the iAPX 286, by 
' irieans of interrupt tasksTgaus^TaSR initiation ifffgaPtlmfc'fespBfSJfT&those events.' " 

Strategy 1 is not viable in a highly protected system. Errors do happen. An erroneous program might 
easily skip a task entirely. A programming erg^^tbat causes a tfght loop in one task would prevent all 
Lptjter tasks from being serviced. , j 

JS ttajte8 y...2 can be adeqiiatft to jislf for certain rjaJstiiae-Systems with a static mix of tasks. Task 
' switching by interrupt is usable in dynamic systems, too, but rarely do all tasks in a dynamic system 
deal exclusively with interrupts. Therefore, in dynamic systems, in highly protected systems, and in 
systems with tasks that do not provide real-time processing, the operating system may need to assist 
Uhe-pocessor with task switching. , i 
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State Model of Task Scheduling 

The role that the operating system must play in using the iAPX 286 task features is most conveniently 
expressed in terms of a state-transition model. To distinguish from the processing state of a task (as 

stored in the TSS), the term scheduling state is used here. Figure 4-2 illustrates; tWe.seheduli^ States 
that a task may assume and the events that may cause a change of state. 

A RUNNING task is the one that the processor is executing. A RUNNING task continues to ^ecute 

until ■ ■ ■ - ".v ' ■'' . 

• It voluntarily gives up control because it needs to wait for some event, such as completion of an 
I/O operation^ data from another program, or the end of a specific period of ^me).' • 

• ,l\ is. pr^n^tedi i-e., forced to giye up control. The interrupt mechanism may cause preemption in 
order to execute an interrupt task, or the operating system may preempt periodically (via timer 
interrupt) to give another task a clmnce to receive its share of the processor's attention. 

A Waiting task may be waiting fo/any of severar events: ' ' " • 

• OaffipfetioHof ar©questtoifie"C®ter I/0 '.r^o ■:'>■:. 

• A signal from another task 

• Data from another task • '^itOilv/ li^lt.hari-..-, yi/.wLi ; , ' :) . 

• The end of a time-delay period . • ' i I " . 

The READY state is really a special case of the WAITING state. A READY task is waiting for one 
specific event: the availabiUty of a processor to execute it. A task becomes READY when first created. 
A WAITING task becomes READY upon occurrence of the event (or events) for which it is waiting. 
A running task becomes READY when preempted. 





\ 

• \ 

I ■> -. ■' 




121960-22 

Figure 4^2i ScHMUIirrgiSMfenf rlmMlion Qfafram > 



4-§ 



121960-001 




TASK MANAGEMENT 



Usually, termination of a task is possible regardless of its scfcig^ll^^nSl^teSBiftefofe, this4i^*apsf^0S 
not illustrate the transition to "terminated" state. 



Interfacing with the Hardware Scheduler .> 

Maoy aj^lcations of the iAPX 286 need both softi«*re schsiulttg (by the operating system) and 
hardware scheduling (by the interrupt mechanism), b«felte><9W(jiSiM»iieis work *ith= Ite SrtBSSsft 
of tasks, you must ensure that they work together harmdnioiisly. Figure 4-3 illustrates the additlSaal 

complexity of dual schedulers. 

Note that scheduling state under hardware scheduling is nearly analogous to scheduling state under 
SOft\yare scheduling. The priority concept, often used in software scheduling, has its analog in the 
primty 'ftifechanism by the interrupt controller. The priority of hardwa.re-scheduled tasks 

relative i;0 sdftwar^-schedtffed tasks is controlled by two factors: 

• The CPU's interrupt-enable flag (IF), and the instruction's CLI (which clears IF) and STI (which 

SKtSiF) .0 ili,, u,.h.. .. ... ■ 

• The 8259A Programmable Interroijt Controller, an LSI cornpongjjt ^b^itoallows selective m^asking 
of interrupts so that software can prevent some external interrupts. 

When IF is set, all hardware-scheduled tasks whose interrupts are not masked out have higher priority 
than all software-scheduled tasks. When IF is reset, all hardware-scheduled tasks have lower priority 
than the currently executing task. Only the operating system (CPL < = lOPL) has the right to execute 
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4-8 



121960-001 



TASK MANAGEMENT 



CLI and STI instructions due to the significant effect that priority setting has on correct, overall 
System operation. 

The ability for an interrupt handler to be an independent task not only protects the handler from the 
rest of ttousjESlsan but also perniits.grfia,ter.flexibility in„thjeJdnds.of fun^ ns an interrupt, handler can- 
perform. An inteitupt handler that is a task can use qperatjpg systfem furiwtions that might change its 
Schaluling state. For example, if an interrupt handler requests the operating system to read a disk 
record, the operating system may change the interrupt handler task's scheduling state from RUNNING 
to WAITING while the I/O operation takes place. (Other tasks may then execute in the meantime.) 
If the interrupt handler were a procedure instead of a task, it would be difficult to identify it separately 
froii' the, taslt that it interrupted. ^ . ; " 

The operating system must keep track of whether a task is attached to an interrupt (i.e., has a task 
gate in the IDT). Occurrence of an interrupt can at any time dispatch, the task attached to the inter- 
rupt. This happens without intervention by the operating system; tBefeflje^when a task calls on operat- 
ing system services, the operating system cannot assume that the calling task is the same as the latest 
software-scheduled task. " ' 

An operating system can easily determine whether the current task is hardware or software scheduled 
if it associates with each task a Boolean that indicates wKeffier the task was software-scheduled. The 
operating system must ensure that only one task at a time is so marked. The operating system can use 
the STR instruction to identify the.airrent task. If the current tasfc.^ not marfc#.» SGft'ware-scheduled, 
then the interrupt mechanism must have dispatched it, ; i 

By knowing whether a task is attached to an interrupt, the operating system can 

• Avoid executing a task that is awaiting an interrupt. A software-scheduled task cannot respond to 
an interrupt. An exception occurs when an interrupt attempts to invoke a busy task. 

• Avoid preempting an executing interrupt task. T^at task shouid finish bdfore software schedules 
another task. 

• Decide what action to take when an interrupt-dispatched task calls on operating-system scheduling 
services. Such action might be to mask off the intqrrui^ otAo pllice a gate for a counting task in the 
IDT to mark lost interrupts^ .. \ '■. ... 

When the operating system changes a task from hardware scheduling to software scheduling, it must 
update the chain of tasks that threads through TSSs. Every hardware scheduled task has a link in its 
TSS to the TSS of the interrupted task. If the system's interrupt structure permits nesting of inter- 
rupts, then the chain of interrupted tasks may be arbitrarily long. To change a task to software-scheduled 
mod#^ thle ©pifating system must take these actions (a£figji^f^44^illustrale8): 

• Reset the nested-task flag (NT) of the current task. 

• Nullify the -bask4ink field in Jfttsbtoef t TSS (as |ffiaiait^ijaL^s© it is ev^r used). 

• Dispatch the prior task on the ba<?k-lini chain. f 

■ -i 

Changing Scheduling State 

In terms of the state model of scheduling, the operating system's job is to effect transitions between 
scheduling states according to the expressed needs of individual tasks and of the application as a whole. 

In many cases, applications drive the scheduling activities of the operating system. Applications express 
their scheduling needs by calls' Operating' systeWl' teetionsttet'iftdirectly relate to scheduling. For 
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example, when an application calls the operating system to request receipt of a message from another 
task, the operating system determines whether a message is waiting for delivery. If no message is 

waiting, then the operating system must switch the task from RUNNING state to WAITING state. 
Later when another task calls the operating system to send a message to the waiting task, the operating 
system must change the task from WAITING state to READY slate. In cases such as these, the 
operating system plays a bookkeeping role, simply keeping track of which tasks are waiting and associ- 
ating events with the correct waiting tasks. 

The operating system plays a much more significant role, however, when it determines which of the 
ready tasks to dispatch (the transition from READY state to RUNNING state) or when to preempt 
the task that is executing (the transition from RUNNING state to READY state). These decisions 
affed the overall performance of the system, both thrm^hpM mA res^opse-l^iextenial events. 



POLICIES AND MECHANISMS 

Because of the difficulty of establishing an effectivie i0idft0t'^&^Atchmg and preemption deicisions, 
it is desirable to clearly separate mechanisms from policies. The only control an operating system can 
exercise over tasks is deciding which task to execute and how long to let it run before changing to 
another task. The scheduling mechanisms must exert such control in a manner that the policies can 
adjust. For example, to control how long a task executes, the scheduler implements a mechanism for 
preempting the task after a certain time period has elapsed. The mechanism consists of an interval 
timer (such as Intel's 8254 Programmable Interval Timer) that interrupts the executing task periodi- 
cally so that the operating systein can deU»'mine., whether the task h^s yet exceeded the time-slice 
allocated to it. The length of the titne'Slice is a variable that the policy layer can control. The policy 
layer sets the length of the time-slice to reflect the importance of the task. 

The separation of policy and inecha«bm ^>plies as to^eddiiag whisjkiitgs^k to execute next. For 
example, the scheduling mechanism associates a priority number with each>^fc< When changing tasks 
it always chooses the task with highest priority. The priority, however, is a variable, and the policy 
layer determines its value. 

For the policy layer to make reasonable decisions about scheduling, the mechanism layer may need to 
collect statistics about the run-time behavior of tasks, for example: 

' Elapsed time in the system - t , 

• Total of actual time serviced by processor 

• Running average of actual length of time-slice 

(Note that interrupt-scheduled tasks subtract from the time allocated to software-scheduled tasks.) 

The privilege levels of the iAPX 286 architecture can support the separation between mechanisms and 
policies. The mechanisms belong to the kernel of the operating system, and as such they should be well 
tested, highly reliable, and not subject to frequent change; in other words, they are good candidates 
for PL 0. Policies, on the other hand, are subject to frequent change and, as a result, are less reliable. 
Running scheduling policies at PL 1 ensures that errors easanot corrupt kernel procedures. 
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SCHEDULING POLICIES ^ ^iuiky^.; . -■■ . 

The actual implementation of scheduling policies depends on the needs of the application and the 
Iteliiviafrof the tasks in the s)«teAT<^^ 

• Gives all tasks equal priority . 

• Allocates the processor once to each task in turn 

• Allocates the same maximum time-slot to each task 

Even this seemingly "fair" policy actually {avojm OMt&iST-^li^ 4^1* others. A task that frequently 
relinquishes the processor voluntarily (because, for example, it frequently has to wait for I/O) rarely 
uses the full time-slot. A "processor-boufld" task (for example, a computational task that uses many 
instructions to accomplish its purpose but rarely does I /O), on the other hand, almost always uses the 
full time-slot, forcing the operating system to preempt it. Over a period of many time-slots, processor- 
bound tasks will receive much more attention from the processor than l/O-bound tasks. Whether this 
situation is desirable depends on the. roles. c^.^^t§^.^t3>i0,0!g^icstk)tL 



Attempting to discriminate against processor-bound tasks by introducing a priority mechanism can 
result in different problems. Suppose all l/O-bound tasks have higher priority than all processor-bound 
tasks. At the end of a time-slice or when a task voluntarily gives up the processor, the scheduler switches 
to one of the higher-priority tasks if one is ready; if none is ready, it switches to one of the lower- 
priority tasks. The problem occurs when there is a such a number of I/O-bound tasks that at least one 
of them is always ready. In this case, the lower-priority, processor-bound tasks iieVef execttte. 

Many more scheduling policies than those outlined here are possible. The examples given merely illus- 
trate how important it is that the characteristics of the tasks in the system be known and that the 
policies match those characteristics. Refer to Coffoian-and Denfling (see "External Literature" in the 
Fretfkeet) for a survey of thesse and otli^^*ei^>'i'"' " sajsrj v^: -f. . i j . . 



Structuring Task Information . . 

If your operating system is to manipulate tasks efficiently, you must structure task-related information 
so that the operating system can get the information it needs as quickly as the application requires. 
The processor implements part of this structure through interlocking links in the GDT. LDT, and TSS. 
In addition to this structure, the operating system must deal with additional state information, which 
might include . 

• The data-segment alias to the task's LDT mU-wa ](■ 'i. .' 

• The data-segment alias to the task's TSS 

• Scheduling state 

f Scheduling parameters (for example, time-slice, priority) 

• Scheduling statistics (for example, total processor time used, average tiiBfe-sHce USetf,' e^Jected 
running time) 

J 

• Links for queues of waiting and ready tasks 
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This additional state information i^ referred toill^ asithe.taskjlatabase (TDB). There are twp comman 
naodes Of acce^ to the task datatosafe TG;/> a:K> 93T'f nfir^ rroV T', ' o 'i^ii • • " . :.. ' 

1 . From within the current task to information about the current task. Most operating system services 
use this mode of access, including the scheduler's time-slice interrupt procedure. 

2. From wit^n- ,the cu^jeijt tas^ |^'|^OTyiation about other tasks. The sc^|^|^l^^j.j|ses this jj^pde^ of 
access to find 't^ne3iMissk^|0^|£X^^tt|^fj,^ : ■■'j - j. rj- 

ACCESS MODE I— ' ' ■ i-' ''-H 3!^? a.'iU'.ol \o>. iison nil's 

Access mode 1 can be efficiently implemented via the GDT. All descriptors for the key segments 
relating to one task reside in adjacent GDT slots. If the operating system can locate one of these 
descriptors (as by using the STR instruction to obtain a selector to the current TSS), then it can locate 
any of the others by a simple addition or subtraction. Figure 4-5 suggests one possible way of organiz- 
ing the TDB. In this example the TDB is stored in a data structure called the taskdnforingttieg i)|Rek 
(TIB). 

1; . ,1 ;■ • ,.- . • ■ ,, . 'inii-. ■ - ' t -. ■ 

la large systems you may need to minimize the number of GDT slots used for task information, so as 

not to unduly limit either the number of tasks or the number of other descriptors that GDT can hold. 
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The example in figure 4-S illustrates the general case in Acluch all the psetii^t information is ini^^a^e 
sepnents. This case uses five ODT slots. You can free one ODT ^stdijtilicluddng the ISS wMiiahte 
TIB. The TIB descriptor can serve as the data-segment alias for the TSS. Figure 4-6 illustrates such a 
configuration. 

Speed of access to the TDB is critical in some applications. Figure 4-7 shows another configuration of 
task information that helps improve access speed. Here the task's stack segment for PL contains both 
the TSS and the TIB. The advantage of this approach is that the TIB and the TSS can be addressed 
relative to the base address that the processor loads into SS when transferring control to a PL-0 operating- 
system procedure. This eliminates the need for loading the DS or ES register to accie^itb^wpeiit 
task's TSS or TIB and also frees a segment rej^ster fctr other use. In such a case, the SP portion of the 
TSS initial stack v^lueS;for PL is set to an offset beyond the TIB. In many applications it is still 
desirable for the QI>T te hold a descriptor for the TIB so as to facilitate access to TIBs for tasks other 
than the current one, v 

Ae<^SSM0DE2 ^. '{< -r: 

When the scheduler is dispatching a different task, it needs quick access to the queues of waiting and 
ready tasks. If the links that implement these queues thread through the many segments that contain 
TIBs, the time needed to search and update the queues is extended by the time needed to load a 



LDT 




121980-g 



121960-001 




segment registec for each segment visite<L J3u$ sugg^ts that these queues all reside together in a 
Separate scheduler queue segment. A pointer in each queue element .can refer back to the correspond* 
tng task. Figure 4-8 illustrates such 9. structured ' 



EXAMPLE OF A DISPATCHER 

the process of changing a READY task to RUNNING state is known as "dispatching." Kgure 4-9 
shows a simple dispatching procedure. This procedure executes at P!L in tie task that calls it. No 
call gate is provided, so only other operating system procedures can call DISPATCHER; for example, 
a procedure that switches the calling task to WAITING state, or a timer interrupt procedure that 
determines when to preempt the task that it interrupts. 

The DISPATCHER procedure is coded in ASM286 instead of PL/M-286 because it is more conveni- 
ent to code an indirect, intertask JMP instruction in ASM286. DISPATCHER makes two assumptions 
about the rest of the operating system that justify the use of an intertask JMP instead of an intertask 
CALL: 

• A task can call operating system procedures that change it from RUNWNG state, so a task does 

not need to execute an IRET for that purpose. 

• The operating system procedure that calls DISPATCHER may set the TSS back link so as to 
intercept an IRET if the task executes one. (When the operating system dispatches a task, it does 
not make sense for an IRET to return to the previously executing task. That task may, for example, 
be waiting for an event and not be ready to execute.) 
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iRPX286 MACRO ASSEMBLRR 



04/22/83 PAGE 



SERIES-III iAPX286 MACRO ASSEMBLER VI . ASSEMBLY OF MODULE DISPATCHER 
OBJECT MODULE PLACED IN :F5;DISP.0BJ 
ASSEMBLER INVOKED BY: ASM286.86 :F5:DISP.ASM 



LOG 


OBJ 




LINE 


SOURCE 










1 +1 
2 


? TITLE ( 


960-583') 








3 
4 


NAME 


DI SPATCHER 








5 


EXTRN 


DEQUEUE READY: FAR 








6 


PUBLIC 


DISPATCHER 








7 
8 


STACK STACKSEG 4 


-00 


04 [J 




9 


TSS PTR EQU 


DWORD PTR [BP-4] 


-ee 


02 t] 




10 


TSS SEL EQD 


WORD PTR [BP-21 


-0004 [) 




11 


TSS_0FFSET EOU 


WORD PTR lBP-4] 








12 












13 


NUCLEUS CODE 


SEGMENT ER PUBLIC 








14 






0000 






15 


DISPATCHER PROC 


NEAR 








16 






0000 






17 


ENTER 


4,0 i WE'LL FORM POINTER ON STACK 


0004 


FA 




18 


CLI 




0005 


9A0000 


e 


19 


CALL 


DEQUEUE READY ; RETURNS SELECTOR IN AX TO TSS 


00A 


300000 




20 


CMP 


AX, ; SAME TASK? 


000D 


74 0B 




21 


JE 


D EXIT ; JUST RETURN 








22 






000F 


8946FE 




23 


MOV 


TSS SEL, AX ; FORM POINTER 


0012 


C746FC0000 




24 


MOV 


TSS OFFSET, ; NOT USED ANYWAY 


0017 


FF6EFC 




25 


JMP 


TSS_PTR ; TASK SWITCH 








26 






0aiA 






27 


D EXIT: 




0O1A 


FB 




28 


STI 


; WHEN THIS TASK EVENTUALLY REGAINS CONTROL, 


0aiB 


C9 




29 


LEAVE 


; IT RESUMES EXECUTING HERE, SINCE THE OFFSET 


001C 


C3 




30 


RET 


; OF THIS INSTRUCTION WAS THE LATEST VALUE IN 








31 
32 




; THE IP REGISTER FOR THIS TASK 








33 
34 


DISPATCHER ENDP 










35 


NUCLEUS CODE 


ENDS 




WARNING #160, 


LINE 


#35, SEGMENT CONTAINS PRIVILEGED INSTRUCTIONS 








36 


END 




ASSEMBLY COMPLETE 


1 


WARNING, 


NO ERRORS 





Figure 4-9. Dispatcher Example 



4-15 



I 



Data Sharing, Aliasing, ^ 
and Synchronization 



CHAPTER 5 

DATA SHARING, ALIASING, AND SYNCHRONIZATION 



sent a need 



Even the simplest rfmltitasking applications present a ifeed for sharing data among tasks. In fact, 
examples presepted in earlier chapters of this book have used data sharing, as in the example proce- 
dures in Chapter 3 that manipulate the free space list. For simplicity, these examples have avoided 
many of the implications of data sharing. However, sharing data among tasks is a complex activity 
that offers many opportunities for pne^task to cause another to fail. Therefore^ for_the protection of the 
system as a wh^e« the operatingiyst»if%ii$t provide services thaH^CTaofe re liable da^a shsMng. 

DATA-SHARING tECHNltt6^S^ i N 1> 



\ 



The af:chitecture of the iAPX 286 allows segments to be shared among tasks through several mecha- 
nisms. Each mechanism has different advantages and disadvantages, ai^ requ'iresjdif&iwtjde^ees of 
support from the operating sys^m. 




Note that while the primary sAbjiect of this chapter is data sheLT^ig,Jlafpe s egment-s haring tcSchniqueS 
apply as well to code segments. ^, / 



Sharing via the GDT X. , 

All tasks in the system can access a segment'ivfaose descriptor resides in the GDT. This mode of sharing 
is especially useful for operating-system databases. Many operating-system procedures can be called 
from any task; they can access system data only if that data resides in segments accessible to every 
task. - —- - „ - - 

Normally, the system designer decides in advance wUch d^criptors are to reside in the GDT and 
which in LDTs, and uses the Builder to install them in the appropriate descriptor table. The only 
support required from the operating system is to provide synchronization for si@mmM the^shaTedidatft; 

frfe not always desirable to use GDT descriptors for sharing segments that only a few tasks use. A 
s^^ent that has a descriptor in the GDT is accessible .bx aU tasks, and exposing it to access from 
uOF^pCed tasks may compromise the system's prd{&$^^ J^yy.^K(j|^d^3l^in^ descriptors may have 
tiitiatciwn effects, because it is diffaimlt tb* contrdl iSk§^f C^^^'W^^&in.^^T'Sjpacc itiy be iSeedfed 
fBi" other purposes. ,-.-....:/ >'-,^':.^ui :^ -.v '^i - ■. 



Sharing via Common LDT 

When two (or more) tasks share most of the segments accessible to either one, then it is feasible for 
them to actually use that same LDT. Figure 5-1 illustrates how to share an LDT by placing the GDT 
selector of the LDT in the LDT fidd iif thie'Tl^ Of mit 'miL , " ^'^ ' ' ' - 

LDT sharing is appropriate if the sharing tasks are designed to cooperate, and if you are willing.to yike 
the risk that a failure in one task might adversely aff^t.t^i&Qtb^^ same LPJ^,! 
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Figure S<1. SegnMnt Siwrffig via CoinRion LDT 

n. .-'.uiTiMsb ffiHriw agnr.vbis .'h iobi-isb th:'; >■ -11,', . 

Sharing via Aliases ■ - -'H /•■/? i^fji-oiq ;riv',', ■ ;-ii;in3-t>. ■ 



When tasks need to share simultaneously some, but not all, segments with selected other tasks, then 
aliasing is an appropriate method. As figure 2-15 illustrates, each task that shares a segment has a copy 
of the descriptor for that segment in its LDT. The term alias is used when there are multiple descrip- 
tors for a segment because eaph descriptor proyidgg m alternate name for the segment. Not all the 
aliases for one segment need to be identical. AliaS» ^y, for example, have different type or diffjei'^at 
access rights. 

Descriptoor manipulation most be restricted to privilege lev^ Q (M. 0), but procedures at any privilege 
level can benefit from aliasing. Therefore, the operating system must provide high-level interfaces that 

cause creation and deletion of aliases. The operating system makes copies of descriptors for the shared 
segments and installs the copies in the LDTs of the sharing tasks (or possibly at other slots in the 
GDT). The operating system must strictly control which tasks may receive copies of which descriptors. 
The presence of multiple copies of a segment's descriptor creates, additioiial complexities for the 
operating system when it relocates, deletes, or ^1^1^ n6iifi^''tfesegkt^^^^^ 

Beware of the confusion that can arise when tasks share data structures that contaia Sete^ni to Uiai 
descriptors. Task A may find a selector that points to a slot in Tiask B's LDT. Nothitfg prevents >Ta^ 
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A from using the selector to reference its own LDT, but if it does so, the selector will likely refer to 
the wrong descriptor. One way to avoid this potential problem is by reservii^ the same slot position in. 
the LDTs of all sharing tasks. 



ALIAS MANAGEMENT 

In any system that uses aliases for segment sharing, the operating system must ensure that all the 
aliases for a given segment remain consistent in spite of changes to the segment. The operating system 
may relocate a segment, transfer it to or from secondary store, or delete the segraent. If allowed to use 
a descriptor that had not been upda-ted- tO'«re^ect any of these changes, a4Bsk rould fail and might 
cause other tasks to fail. Therefore^ .an jopergtlhg system must impiemen}>r<gb,meai s to find and update 
all aliases for a seginent when itichanges any one c^tfaersdmsss. i — 



^ X 

Alias Database , , 

Figure 5-2 shows an example method for locating ahases. This method maintains a header block for 
each segment that has aliases. Pointers to all the aliases for that segment are linked to the header. As 
long as the entire list does not span more than one segment, the link fields (FIRST, LAST, NEXT, 
PRIOR, and HEADER) need only contain offsets. The doubly linked ^t^pwn here aids dynamic 
creation and deletion of alias pointers; for static systems, a singlylinked^stiimidd suffice. 

In addition to the FIRST and LAST links, the list header contains that segment information that might 
change but that must remain consistent in all the aliases of a segment. Operating-system operations on 
segments demand that the segment base address and the present bit be consistent. Furthermore, any 
interrogation of the accessed bit for a segment demands that the accessed bits in all the aliases be 
ORed together. This example assumes that the operating system does not permit creation of aliases 
mtiiJdifferiiig limit or expansion direction. - 

When a task that has a selector for an alias descriptor calls on operating system functions that make 
changes to segment attributes, those changes must be broadcast to all other aliases for the segment. 
Therefore, the operating system roust have a means, gjven any descriptor, to find the alias list that 
includes that descriptor. Figure 5-3 illustrates one technique for doing this. Each descriptor table has 
a parallel table of pointers to alias list headers. The index in a selector that locates a descriptor in the 
descriptor table also locates a pointer in the parallel table. A descriptor that has no alias has a null 
entry in the corresponding position in the parallel table. For applications in which aliases are few, you 
can employ a hashing algorithm to reduce the number of entries in the parallel table. 



Alias Procedures 

Iftlplementation of procedures fbi^'alias management for the 80286 is a straightforward application of 
list processing algorithms and therefore is not illustrated here. At a minimum, the operating system 
should provide a GREATE_ALlMS'p'ocedure and a DELETE_ALIAS procedure. 

The operating system must enforce a correspondence between the existence of descriptors for a segment 
and the existence of the segment itself. A segment must always have a descriptor, and an active 
descriptor must always point to a valid segment. A convenient way to enforce these rules is to permit 
only the DELETE_ALIAS procedure to call the segment FREE procedure. DELETE_ALIAS should 
cause deletion of a segment Only when the last descriptor fst the segment has been deleted. 

Citating an alias is only the first step toward segment sharing. The CREATE_ALIAS procedure can 
only create an alias for a segment that is accessible to the task that calls CREATE_ALIAS. Tlie next 
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UNKED LIST OF POMTBIS TO ALMS DESCMPTORS 
FORONeSEGMEMT 




:ilr to - ii_ ■ . . f,-.;.i 

Figure 5-2. Alias List 



step toward segment sharing is to pass the alias to another task. This subject is taken up in a later 
SYNCHRONIZATION 



Consider the example of a memory manager given in Chapter S.^While a memory management proce- 
dure manipulates the links that manage free space, Pf>il4^nts when the data in the links 
temporarily inconsistent (for example, yjpj\§g<;p^^ ||M|,i||eg|[|^J)^s.^^n sc^, bul, jlte,pre){i(Hif. 
pointer in the next segment has not yet been ispdated). If ^e proic^^ interrupts the task in wUefa the 
memQry-mana^ineiLt.procedure is running to run another task (or even another procedure in the same 
tiisk) and if the '^esvf, task (or procedure) calls the memory manager, then the the memory manager is 
likely to behav|%inj^ectly» 



For the protection of the system, the operating system must prevent such forms of incorrect function 
in its own logic and must Vroyi^^fmf$>^^m^ m & ff ^ ^^^&0 ^Pi^ application logip to avQi^ s»}<* 
failures as well. • --ni ii-a c, A r:-<, i^^wru-i- ^ " ■ 
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HEADER 

□ 



□ □ 



□ 



^^£;i@vk 



□ 
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Low-Level Mutual Exclusion 

n ji , 

The most basic form of 'Synchromraiti^i»«ontTd owi'imti^^ctiSns. A critical section is a siequence 
of instructions that operates on shared resources in such a way that errors could result if another 
sequence of instructions operated on the same resources within the same time span. Any means that 
prevents any two critical sections from overlapping in time would prevent such errors. In a single- 
processor system, only an interrupt can cause the operations of one critical section to interleave with 
those of another. Disabling interrUitSil^&ddl^ the $^^manf imtue^ exclusion. 



Procedures that disable interrupts to provide mutual exclusion must adhere to certain rules: 

• Determine the maximum permissible delay for servicing an interrupt, and do not code a critical 

section that takes more time. 



• Avoid causing a fault that might keep interrupts disabled for a longer time than permissible. 
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Do not nest critical sections; there is only one interrupt flag. ' 
Do not switch tasks; doing so may enable interrupts. 



Disabling interrupts as a means to pi:oxidfi,niMtual exclusion is not a i ^nera llv applicable technique, 
fh^ rules above are too restrictive for many situations, and the CLI and STIiinstructions for disabling 
md enabling interrupts are restricted to procedures whose CPL dora not n4merically exceed IOJ*L, 
Kn operating system can, however, use this technique for its jown short-tom, high-speed exclufion 
"eqpirements and as the basis for more geffi^tf 'synphronization Operations. ' ' 



■figli-Level Mutual Exclusion 



\ unore-generally applicable form of mutual exclusion must permit interleaving (via interrupts and 
K>f^ware task switching) of unrelated critical sections. 



t 



□ 



I 



/, 



// 



SEMAF^ORE DATA STRU6TURE 

Ol / / 
e fdr,impiementin| a^sneral purpose form of ^ntrof 
jver critical sections: binary sem.aphores. The semaphore structure'cSSTsts of a counter and a queue. 
lEvery shared resource subject to the effects of contention nee^ one semaphore structure to provide 
putual exclusion for the tasks jisingthe_resqurM^^^ \ \ 



The value of the counter is one minus the number of tasks waiting at the semaphore. A value of one 
indicates,that the semaphor^igl ava|J[gb|B; a value of) zero indi<^tc$ the the sen^phore h^s been acqu^ed 



t 1 



SBMPHORE 



SCHEDULER QUEUE SEGMENT 



HEAD OF' 
QUEUE 




QUEUE 



!o aroiJiii'. r>i . ->Aj 



B I ! 



T 



L J 



TO TASK 
ENTRIES 
MGDT 



" ''" ■ 121960-28 
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but no other tasks are waiting for the semaphore; a negative value tflfliicaies that some tasks are queued, 
waiting for the semaphore to be released. The queue is circular so that the pointer to the head of the; 
queue also identifies the tail of the queue. . 

Semaphore structures may be stored individually in separate segments or may be stored together in 
one or more segments. In the latter case the operating system must provide a means for identifying 
individual semaphores within a s^imenf. StMng the stai(fh#i e«jante>r''fii a segtfient by itself yields 
two important advantages: 

• The processor can individually protect each semaphore. r k ; j . ,< 

• The selector of the descriptor for the semaphore segment serm as * ceWvenient identifier for the; 
, semaphore, ' 

Semaphore structures are sensitive data that must be cloistered behind the level protection wall. 
Semaphores may reside either in the GDT or in the LDTs of the tasks that use them. The same! 
|;(msideratioi« apply as for sha^e^l.4a^ s^g^^^cp^s. , • ■ ' ■ 

jSEMAPHORE-MANAGEMENTf^ROCieUHES 

The minimum set of operating-system procedures needed to use semaphores includes 

f WAIT_SEMAPHORE to acquire a semaphore if it is flot j 

^ SIGNAL_SEMAPHORE to signal departure from a i^M^kl'iectiOit.; ./ , 

Dynamic systems may also need to define semapbofes dyttafiiieally with procedures siich as 

f CREATB3EMAPHQ1E for setting up a pew sem^ghore ^|j^0^rp , , ■ 
f DELETE_SEMAPH0RE to eliminate a semaphore structure that is no longer needed 

iThe operating system's responsibilities in nianaging binary semaphores include 

• Ensuring that no more than one task holds a semaphore -7 -1 

• When a task requests a semaphore that to not Jjeen ligna&dj-f lasjiii 4e task in a waiting queue* 
I and dispatching another task • jo . ii i'v?, •■ 

• When a task signals a se3maphore, awakening the next task in'" ^ waiting queue for that'»maphori 
and placing it in the ready queue 

• Preventing or being prepared to handli! di^i^oefcithat map- jjqsud* from using semaphores 

tigure 5-5 shows simple examples of how to use a low-level synchronization technique to implement 
WArT_SEMAPHORE and SIGNAL_SEMAPHORE procedures. These procedures must run at 
PL to access the semaphore &traictur£&_With..segment.descriptors in the GDT and with call gates at 
PL 3, any procedure in the system can cat! ttoese:^ncl8"onizati»n:|Jiiiniitives. 
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PL/M- 


■286 


COMPILER 960-504 'date' ' PAGE 1 


COMPILER imOKED .^Y^. .-BLtfZ^^MrrP3XifiPitimiELHr^m ;i . i •:». 






$ PAGEWIDTH(71) TITLE (' 960-504 ' ) INCLUDE ( :Fl : NOCSUB. PLM) 
= $ NOLIST if,;-:i - ' . ■.' j'i . 






SBMAPB:,', -jgO; .. • ■ - --d' 

****************** ************************************ y 

/* Externals */ 


1 ::.v rtotra. 

. -f! : 3 


"I 
2 


D I SPAfS-BES J -PROCEDURE EXTERNAL; 
BHOi-MSPMCteRji U J 


4 

5 

6 


1 
2 
2 


ENQUEUE_WAIT: PROCEDURE (QUEUE_ID) EXTERNAL; 
DECLARE QUEUE ID SELECTOR; 

END ENQUEUE_WaTt; 


7 
8 
9 


1 
2 
2 


DEQUEUE WAIT: PROCEDURE (QUEUE ID,EXCEP P) EXTERNAt; ' ' • 

BECLJkRE QOEOB 10 SELBCTlOS, EXCBP P POINTER; 
END DBSOSOB WaTT; 

/******************************************************* / 

/* Semaphore Data Structures */ 


10 


1 


-,- ■ /I.. * ■ . . ' 

DECLARE SEMAPHORMAT LITERALLY 
'FILLER (2)- WORDr . i 
COONTER 'MOR'tj* J ■"'■ ]'■■ '': ''■'■ ■' ■ I-- 


11 


1 


DECLARE OK LITERALLY ' ' ; 


12 


1 


/* ****************************************************** y 

/* Test a semaphore; wait if not set */ 

WAIT SEiHAHidREV'"^9«gSfe«l6 ''(i^i^'^i^r MtP P) ' ^ ' 

PO^WC REENTRAilT; 


13 


2 


DECLARE SEMAPH_ID SELECTOR, 


14 


2 


DECLARE EXCEP P POINTER, 
EXCEP BASED EXCEP_P WORD; 


15 
16 
17 
18 
19 
20 
21 
22 


2 
2 
2 
2 
3 
3 
3 
3 


DISABLE; ' 
S EMAPH.COUNTER=S EM APH .COUNT ER-1 ; 
IF ZERO /* Test the zero flag. */ 
THEN /* Semaphore was set. */ DO; 

ENABLE; 

EXCEP=OK; 

RETURN;' 

END; --'■-■^ '■ ' 


23 


2 


/* Semaphore is not set; this tas* '^rttStfgfrtSit. */ • 
CALL ENQUEUE_WAIT (SEMAPH ID); 

■■'!.'■• ' 
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PL/M-2 86 COMPILER ' 9€i^59'4 •• • " ■• i.'-r, ' "a^l^e -M' ' pj^Qg j- 

24 2 ENABLE; - - ., ' 

25 2 CALL DISPATCHER; ■ - • . 

26 2 END WAIT_SEMAPHORE; 

/**************************#****************************/ 

27 1 SIGNAL_SEMAPHOREz PROCEDURE (SEMAPH_ID, EXCEP_P) ' 

PUBLIC REENTRANT; 

28 2 DECLARE SKMAPH_1D SELECTOR, 

SEMAPH BASED SEMAPH_ID STRUCTURE (SEMAPHORMAT) ; 

29 2 DECLARE EXCEP_P POINTER, 

EXCBP- B'ASfiD- EXCEP P WORD; 

;-l ni, ^>i'*i T _!-^ i-nii;: iM^'^''; ."'■.K'^!^:■ ' ■ ■ ■ 

30 2 DISABLE; 

31 2 SEMAPH. C0UNTER = SEMAPH.C0UNTER + 1; 

32 2 IF NOT (ZERO OR SIGN) /* Test flags. */ 

33 2 THEN /* No one is waiting at this semaphore. */ DO; 

34 3 enable; 

35 3 EXCEP=OK; 

36 3 RETURN; 

37 3 . END; 



/* Someone is waiting at this semaphore. */ 
CALL DEQUEUE WAIT (SEMAPH ID, gEXCEP) ; 
ENABLE? ' • - i^t^i r; - id^r " N .nr" ' 

40 2 CALL DISPATCHER; 

41 2 EXCEP-dKr ^ ••I -i^r:'}--: ; - . 



38 2 

39 2 



43 1 END SEMAPH; 



MODULE INFORMATION: 



CODE A1S6A SIZE 


= 0084H 


132D 






CONSTANT AREA SIZE 


= 0000H 


0D 






VARIABLE AREA SIZE 


= 0000H 


0D 




MAXIMUM STACK SIZE 


= 0010H 






• ' f{.h Mi;.;. 


107 LINES READ 










PROGRAM WARNINGS 










PROGRAM ERRORS- 










ONARY SUMMARY: 




Ui-i isdjo BO 


pfTOOffioq') 


rnoi'i o.ir.^ v • ■ 


91KB MEMORY AVAILABLE 






sbr aril ■ ' . 


4KB MEMORY USED 


(4%) 









0KB DISK SPACE USED ,, , , 

END OP 'BL/H<^286 COMPIISATIOW H,' "! ^ ' ^TO I - : tfi-.r • '-f 



Fi9ur»#«i. SeniaplioraiiExanipl»-(G0at'#.)s 
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^OTHER FORMS OF SYNCHRONIZATION 

j You may wish to, implement other fomis of synchronization; 6p.e3|^ 

!• Conditional variation of WATTJSEMAPHORE that docs not force a task to wait when the semaphore 
1 has not been signalled. 

I* Hined waiting, so that a task can be awakened if the semaphore is not signalled within a reasonablb 

time. (This helps guard against deadlocks.) 

• An extension of the semaphore concept known as a region. A region is similar to a semaphore except 
I that bnly the task that acquires a region can rel^se (spiai) it, and a task that holds a region caiuiQt 
be suspended. ..... tv-vD.-- f>i= - ]/.;!;.■! ' j 



MESSAGE PASSING 

Message passing is a general purpose means for transferring data from the address space of one task 
to the address space of another, cooperating task. Tfhere are two aspects to the technique: j 

> Transferring data from a segment in one task's address space into a segDiient in the receiving task's 

space „ . ' 

• Transferring a segment from one task's space into another's 

The first case is suitable for passing relatively small amounts of data, such as parameters, information 
describing events, etc. The second case has two primary applications: i 

• For transferring large "consumable resourees*' such as I/O bu^is j ; | 

• For transferring aliases that implement the previously (fescribiecl^^tllol of "sharing via aliases" 

jWhen an alias is passed as part of a message, the c^iehitfi^ s^eiB'inslalb' the alias in a descriptorj- 
jtable slot 4etermined by the. ^^j\[ii>g,^|^, ....,,,.-,,»,,...,.,. • 

Message-Passing Example 

Figure 5-6 shows an example data structure for implementing a simple form of message passing. This 
structure defines a mailbox, a queue of tasks waiting for messages from the mailbox, and a queue of 
undelivered messages. The system may contain one mailbox for every conrmiunicatjioa channel between 
tasks. For simplicity, this example assumes that the format of messages for all m^lxs^ is the sain4 
consisting of a fixed-length data item and two d^riptor£i'-' ^ ''^ ' 

[f each mailbox resides in a unique segment, then these advantages r^^ 

> Mailboxes are protected from operations on other niailboxes. ■■tuf-.f . . . • 

> A selector can serve as the identifier of a mailbox. 3Jfc 

Only the sending and receiving tasks need access to a mailbox; therefore, the appropriate tables for 
descriptors for mailbox segments are the LDTs of each of the tasks that share a mailbox. All tasks cart 

share a global mailbox, however, if its descriptor is in the GDT. The DPL for all mailbox segments 
should be zero to prevent procedures outside the operating system from interfering with message passing. 

Mailboxes require at least two procedures: SEND_MESSAGE and RECEIVE_MESSAGE. Figure 
S-7 shows examples of these; .fn'dcedM«di£^Both^it«sdi»«»«fos<£^-i^ to access level-0 mailbox 
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" ''v ^ ; ' : .ii:- 



SCHEDULER QUEUE SEGMENT 



MAILBOX 



TASK QUEUE 
POINTER 



HEAD OF 

Message 

QUEUE 



TAIL OF 

message 

QUEUE 




1 



QUEUE 

elements 



n [ 



1 



OueUE OF UNOEUWBW MESSAOES 

next data o^apgm^ms 
I I I - ' ■ 1 




TO TASK 

' Entries 

INGOT 



■'II ':■}> jjinm 



./,;i"-fci i;m fn;; 
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jSegments. If there are call gates in the GDT at PL 3, then these procedures" are accessible to all oth^ 
{procedures in the system. 

SEND_MESSAGE fills a message with the specified data and descriptors, removes the descriptors 
^rom the descriptor table, and links the message at the tail of the message queue. If a task is waiting 
jat the mailbox, SEND3tESSAGE causes it to be linked into the ready queue so that it will find the 
message the next time it is scheduled to run. 

er RECEIVE_MESSAGE finds no messages waiting at the omUboXr-thf n it links the task into a waiting 
ueue. The task queue threads through the task database. The task wiU Continue executing when aiioUie|^ 
task sends a message to the mailbox. If (or when) a message is waiting, RECEIVEJMESSAGE write? 
the data portion of the message at a spepified location in the receiving task's space and installs th4 
jdescriptor portion in sped{i«d-^ots|in ^ne t)ie recet^i% task's descriptor tables (GDT or LDT). | 

These examples do not include management of space and queues for messages because conventional 
algorithms apply. External procedures GET_MSG_SPACE, ENQUEUE_MESSAGEi 
DEQUEUE_MESSAGE, and FREE_MSG_SPACE provide these functions. 

f 1 i ! f I \ i 

Special handling is required to accommodate the fact that a descriptoil hx a message is temporarily not 
in any descriptor table. There are two cases to consider: 

The descriptor is the sole descriptor for the segment. In this case, no changes can be made to the 
segment because it is temporarily inaccessible. You should take care that no failure iitthe commur 
nication process causes the descriptor to become lost. A memory area withotlt a d'^HP^^"' cannot 

be freed. ' S 

The descriptor is an alias (i.e., one of several descriptors for the same segment). Since the segment 
is (presumably) accessible via the other aliases, it is possible for some task to request some operation 
on the segment during the time the descriptor in the message is absent from any descriptor table. 
Normally, the operating system updates all aliases when it makes any major changes to a segment 
(for example, relocation or swapping to secondaiy stor^. This is not possible (given the aliasing 
sdieme previously pre^ted ia tMs cliapt^) wkten tl»e a^ is not in a descriptor table. To solve thi 



I»oblem, this example kssumes theie ai-e two temeedam&i 



i \ 



t 



a. DISABLE_ALIASiJ»TR nm- B H F liy t hr alte 'ti CT l aa g^t to i^cateUo the alias manager that 
the alias is in a mailbox ' | ' ; 

b. FIX_ALIAS_PTR ithat, wp^lfiS'ffig^ge is delivered, updates the alias pointer with the ne4 
location of the alias/ md v^ f tmy - a cg i faOT t-arformfttieii'ihat tn^y have changed while the aliai 

was absent from the alms list. i ! 

I I 

' i 

toynamic systems may nee&Wcteate and delete mailboxes dynamically. The only difficulty in creating 
a mailbox is ensuring that no task uses it while it is being constructed. (The next section considers this 
problem.) To delete a mailbox the operating system must awaken any tasks that are waiting for messages, 
delete any descriptors (aliases) that reside in undelivered messages, and delete the undelivered messages 
fthemselves. ] 

The operating system may, as part of the process of task creation, give each task at least one mailbox. 
If the mailbox feature is the only means of passing aliases among tasks, a task cannot receive an alias 
for a mailbox unless it already has a mailbox. Some operating system designs may require every task 
to have a mailbox for such purpose#i^^^l»^ll]^^t^6ry)^iaiMilrom the memory-allocation module. 
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PL/M-286 


COMPILER 960-508 date , . PAGE 1 


system-ID PL/M-286 Vx.y COMPILATION OF, , -MODULE ,!f&II,^QX 
OBJECT MODULE PLACED IN :F1:MB0X.0BJ " 
COMPILER INVOKED BY! PLM286 . 86 ' : fltfiSOX. PLM DEBUG 






$ PAGEWIDTHdl) TITPE('960-508;), mCLHOE. (:F1:N0CS0B.PLM) 
$ NOLIST . ■ . ' ■ 


1 




MAILBOX: DO; ' 

/**lrlli*%4»***»*********»***»* ******** / 

/* Definitions */ 


2 


1 


DECLARE FAILED LITERALLY '80008', 

., 0K LITERALLY I i ............. . 

^'k ***illt4i!'illrir*'4**4r*#3ril*ikAW#AA 4r ****** *** * * * * *.* *********** y 

/* . Externals */ 


3 
4 

5 


1 
2 

2 


NULLIFY: PROCEDURE (SLOT) EXTERNAL; 
DECLARE SLOT SELECTOR; 

END NULLIFY; 


6 
7 

8 


1 
2 

2 


STORE DESCR: PROCEDURE (SLOT, PTR) EXTERNAL; 
DECLARE SLOT,f f J.fCfOR, . , » 
PTr' 'pointer; • • . • - 
END STORE_DESCR; 


9 
10 

11 


1 
2 

2 


LOAD DESCR: PROCEDURE (PTR, SLOT) EXTERNAL; 
DECLARE PTR POINTER, 
SLOT SELECTOR; 
END LOADJDBSCR; aj ■• ,^ 


12 
13 


1 
2 


DISPATCHER: PROCEDURE EXTERNAL; 
END DISPATCHER; 


14 
15 
16 


1 
2 
2 


ENQUEUE WAIT: PROCEDURE (QUEUE tb) ' EXTERNAL; 

DECLARE QUEUE ID SELECTOR; ^ _ , 
END ENQUEUE^WAiyj' 


17 
18 
19 


1 
2 
2 


DEQUEUE WAIT: PROCEDURE (QUEUE ID, EXCEP P) EXTERNAL; 

DECLARE QUEUE ID SELECTOR, EXCEP P POINTER; 
END DEQUEUE_WAYt; ~ 


20 
21 
22 


1 
2 
2 


DISABLE ALIAS PTR: PROCEDURE (SLOT) EXTERNAL; 

DECLARE SLOT SELECTOR; : 
END DISABLE_ALIAS_PTR; ' 


23 
24 
25 


1 
2 
2 


PiX ALIAS PTR: PROCEDURE (ALIAS LIST ID) EXTERNAL; 

DECLARE ALIAS LIST ID POINTER; 
END FIX ALllV'r^rs --'^y'^^ni iT-ois; 


26 
27 
28 


1 
2 
2 


GET MSG SPACES PR{^^)^^( BOX ID, MSG P P, EXCEP P) EXTERNAL; 

DECLAIff bW ID'^ SltECTOR, (MSG P P, EXCEP P) POINTER; 
END GET MSG SPACEj 
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PL/M-286 COMPILER sH-See date ' PAGe"' 2 

29 1 FREE_MSG_SPACE: PROCEDURE (BOX_I D^Mgg' ^TR) EXTERNAL; . 

30 2 DECLARE BOX_ID SELECTOR, ^'-r^.-T^ .' 

MSG_PTR poimiii . ■ 

31 2 END FREE_MSG_SPACE; 

32 1 ENQUEUE MESSAGE: PROCEDURE (BOX_rD^MSG_PTR) EXTERNAL; 

33 2 I)ECLARl'aiOX_ID SELECTOR, _ 

MSG_PTR POINTER; 

34 2 END ENQOEUE_MESSAGE; 

35 1 DEQUEUE_MESSAGE: BROCEDURE (BOX_ID, MSG_P_P , EXCEP_P) 

EXTERNAL; 

36 2 DECLARE BOX_ID SELECTOR, (MSG_P_P, EXCEP_P) POINTER; 
37. 2 END DEQUEOE_i.^SSAGE; .!■,,],-.• aaAj'.a ■ 

/**»»**»**»»»»»»» t**»*»*»»*»**»»**i'iii***1l********»****** y 

. . ■ /* , , . -r . . - w<{i?ilb«>if,P«taiStrvict:BEe§, . . */ 

38 1 DECLARE MDATA_SIZE LITERALLY '46'; 

39 1 DECLARE MESSAC5E_B'6rMAT :-'t1SgRALLY 

'MDATA (MDATA_SIZE)I BStf-^ 
DESCRl (4) WQKb, 
, ,^E^g3M -<4)l-: WORD,'* . . 

/* Send Message via Mailbox */ 

40 1 SEND_MESSAGE: PROCEDURE (BOX_ID, MDATA_ET,R^ SLOTl, SL0T2, 

EXCEP_P) ^,;,?^8LIC reentrant; 

41 2 DECLARE BOX_ID SELECTOR, .. , 

MDATA_PTR POINTER, 
(SLOTl, SL0T2) SELECTOR; , 



42 2 DECLARE EXCEP_P 

EXCEP BASED EXCEP_P WORD; 

43 2 DECLARE MSG_PTR POINTER,.-., jn;-\,.-...' 

MESSAGE BASED MSG_Pt4! %l%W*8ftE "' 

44 2 c'kiL''6ETjMlfef^^>A{:E(B0X_ID, @MSG_PTR, @EXCEP) ; ' ^, 

45 2 IF EXCEP=FAILED THEN /* the box is full of messages */ 
4 6 2 DO; . 

47 3 CALL DISPATCHER; ... ^ , •• - 

48 3 RETURN; 

49 3 END; ' 

/* The raisx^ statement will cause an exception if the 
iiegmeht containing the data is not present. 
Therefore interrupts af,». eniabled.., ^' ,-„^, */ 

50 2 CALL MOVE (MDATA_PTR,@MES&AGE.MDATA,MbATA^SlZE) ; 

51 2 IF SL0Tl=SELE9Tf^pfijiyUA-.,, . .. 

52 2 THEN MESSA(S&,ttffiSC|S3W^'V*. Mar,k'''^^'j^^^^ 

53 2 ELSE DO; ' ' . ,,|7 

54 3 CALL STORE_DESCR(SL0Tl,iaMESSAGE. DESCRl);" 

55 3 CALL DISABLE ALIAS PTR (SLOTl); 
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56 3 CALt NULLIFY (SLOTl) ; 

57 3 END; 

58 2 IF SL0T2=SELECT0R$0F(NIL) 

59 2 THEN MESS AGE . DESCR2 (2 ) =0 ; /* Mark as null */ 

60 2 ELSE DO; 

61 3 CALL STORE_DESCR(SLOT2,@MESSAGE.DESCR2) ; 

62 3 CALL DISABLEALIASPTR (SL0T2) ; 

63 3 CALL NULLIFY (SL0T2) ; 

64 3 END; 

65 2 DISABLE; 

66 2 CALL ENQUEUE_MESSAGE (SOX_ID, MSG_PTR) ; 

67 2 CALL DEQUEUE_WAIT (BOX_ID,@EXCEP) ; 

68 2 ENABLE; 

69 2 CALL DISPATCHER; 

70 2 RETURN; 

71 2 END SEND_MESSAGE; 

^* ****************************************************** ^ 

/* Receive Message from Mailbox */ 

72 1 RECEIVE_MESSAGE: PROCEDURE (BOX_ID, MDATA_PTR , SLOTl, 

SL0T2, EXCEP_P) PUBLIC REENTRANT; 

73 2 DECLARE BOX_ID SELECTOR, 

MDATA_PTR POINTER, 
(SLOTl, SL0T2) SELECTOR; 

74 2 DECLARE EXCEP_P POINTER, 

EXCBP BASED EXCEP_P WQ|!D; 

75 2 DECLARE MSG_PTR POINTER, 

MESSAGE BASED MSGPTR STRUCTURE 
(MESSAGE_FORMAT) ; 

76 2 CHECK_MAIL: 

DISABLE; 

77 2 CALL DEQUEUEMESSAGE (BOX_ID, @MSG_PTR, @EXCEP) ; 

78 2 IF EXCEP=FAILED THEN /* No mail today-*/ 

79 2 DO; ■■ " - ' ■ 

80 3 CALL EN(3UEUE_WAIT (BOX_ID); 

81 3 ENABLE; 

82 3 CALL DISPATCHER; 

83 3 GOTO CHECK_MAIL; .inf-r'f , ■: .i;*' - 

84 3 END; 

85 2 ENABLE; , 

/* Next statement may cause exception. */ 

86 2 CALL MOVB (@MESSAGE.MDATA, MDATA_PTR, MDATA_SIZE); 

87 2 IF MESSAGE. DESCR1(2)<>0 /* Test for null descriptor */ 

88 2 THEN DO; 

89 3 CALL L0AD_DESCR(§MESSAGE.DESCR1, SLOTl); 

90 3 CALL FIX ALIAS_PTR (SMESSAGE.DESCRl) ; 

91 3 ■ END; ' ■ 

92 2 IF MESSAGE. DESCR2(2)<>B /* Test for null despciptor */ 

93 2 THEN DO; 

94 3 CALL LOAD DESCR ( ^MESSAGE . DESCR2 , SL0T2) ; 



Figure 5^7. Example of Malffodx 9iieeedurd# (C«»At'd.) 
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Pt/M-2'86 COMPILER 96%--5'08 Sat*' PAGE 4 

95 3 CRLL FIX_ALIAS_PTR (1§MtWlA^.Efefe'8tf'2) ' ' 

9:6 3 END; ,1" 

97 2 CALL FREE_MSG_SPACE(BOX_ID,@MESSAGE-); 

98 2 EXCEP=OK; . . ' ' ': 

99 2 END RECEIVE_MESSAGE; ; ■ ; , 

y****** ********** **»**^******^i^^^^'*>**^ 

100 1 END MftlW.O^i^^,. 



MODULE INFORMATION: 

CODE AREA SIZE = 016EH 3660 , , ' •■ 

CONSTANT AREA SIZE = 0000H 0D 

VARIABLE AREA SIZE = 0000H 0D . ,. 

, MAXIMUM STACK SIZE = 0020H 32D 
193 LINES READ ' 

PROGRAM WARNINGS ., , 

PROGRAM ERRORS - 4-^^"' „^ ' " ' ' 

DICTIONARY SUMMARY: 

91KB MEMORY AVAILABLE 
6KB MEMORY USED (6%) 

0KB DISK SPACE nS6BHT-„T a '>3')y/ 



END OF PL/M-2 86 COMPI LAtlOti' 



Flgur^ 5-7. Exain^ie of Mailbox Procedures (CoAt'd.) 



j/ariations on the Mailbox Theme .^a^^''^- 



^ome of the features appropriate for semaphores are also appropriate for mailboxes, namely: 
i Conditional receive "V ^ ■ ; ; 



I 



Timed wait 



For applications in which speed is not the overriding goal, mailboxes can substitute for semaphores. A 
mailbox is analogous to a semaphore, with the counter of a semaphore corresponding to the number of 
teessages waiting at a mailbp?!-, ^ m^^j|,|s«^ fluU,.mesf?^g^s is id^^^ function to a s^ipaphore. i 



est applications that use mailbox^ require ^ffiiFcat taiessage formats (different data size, different' 
number of descriptors) for different communication channels. With dynamically created mailboxes, 
ioessage format may be defined by parameters^to the creation procedure, encoded in the mailbox, and 
interpreted by the SENDiMil$SAl3E^i«i)&E@ifi^dMei^SMi£ ptetiedures. 
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Systems that implement "pipes" as a form of intertask communication can call mailbox procedures 
from the device drivers for the pipes. 

It is possible to use mailboxes as the sole means of interface between applications and operating system. 
For example, the operating system has one mailbox through which it receives service requests from all 
applications; each task has a mailbox through which it receives responses from the operating system. 
To get more memory, a task would send a memory request message to the operating system; the operat- 
ing system would return a message containing an alias for the allocated memory segment and install 
the alias in the task's LDT. The advantage is simplicity. Only two global gates are needed: one for 
SEND_MESSAGE and one for RECEIVE3IESSAGE. A task can wait for only one purpose: for a 
message from a mailbox. The disadvantage is inefficiency. Any impleimitation ai mailboxes is bound 
to be less efficient than the interlevel CALL instruction normally used to communicate with an operating 
system. 

All of these forms of message-passing can use the primitive synchronization and descriptor-manipulation 
techniques illustrated in this section.B 
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Signals and Interrupts 



s 



CHAPTER 6 
SIGNALS AND INTERRUPTS 



Interrupts are a mechanism long used in single-task microprocessors for reacting quickly to external 
events. In the Jasuithasldng archite^iire (^ tlie lAPX 286, each task may have the same needs for 
information about external events ks tbe-ofie task in a sin^e-task^ystcm. En a multitasking system, 
several generalizations of interrupts are useful: 

• Some tasks may do nothing but service a specific external event. While the task waits for an event 
to occur, the processor can service other tasks. 

• Information about an external event must be routed to the correct task. 

• Events external to a task may include events occurring in other tasks as well as events external to 
the processor. > 

• The ability to selectively ignore events mtist the* ex^ind tb thosei events occurring in other tasks. 

• Each task can benefit from a vector table to a\itom%ticall5f route informatioii, about events to the 
correct handler procedures within the task. 

• Scheduling of tasks that service 'events must be coordinated with the software .scheduler, while 
retaining the ability to respond rapidly to events. 

The 80286 implements some of these generalizations of interrupts onto the multitasking environment, 
but the operating system has responsibility for others. Not all are relevant to every application of the 
80286. 



INTERRUPT FEATURES OF THE iAPX 28frfARCHITEGTiUlE 

The iAPX 286 architecture inchidesa^nmiriber«£feaUtresrilirai>waik;tie^tiierto efficient response 
toevents. ' ' 



Vectoring 

The processor associates each event with an identifying number in the range 0-255. The processor 
recognizes three classes of events: 

• External. Events occurring outside the 80286 processor's environment are communicated to the 
processor via the INTR or NMI (riim-^m^Wi interrupt) pins. The NMl is interrupt 2. Other 
external interrupts share the INTR pin via one or more 8259A Programmable Interrupt Controllers, 
which can map each interruptta a'un^ilrinterru^iHrli>in1tecrraiB®e'92--255. 

• Processor. When the processor detects a condition that it cannot handle, it communicates tliis fact 
by causing an interrupt with an ID in the range 0-16 (except for interrupt 2, which is the NMI). 

• ■ :Software. Programs can generate signal events by executing the instructions INT n and INTO. 

With INT n, the value of n can be any interrupt indentifier in the range 0-255. This gives software 
the ability to simulate hardware interrupts as well as the ability to cause interrupts that are not 
directly associated with hardware events. (Note that many software systems use the software inter- 
rupt to call on operating-system services. With the iAPX 286, an interlevel CALL through a CALL 
gate serves this purpose.) ^ ■ 
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When an interrupt occurs, the processor uses the interrupt identifier as an index into the interrupt 
descriptor table (IDT). 



Enabling and Disabling Interrupts 

The interrupt flag (IF) controls whether the processor immediately reacts to external events, .MWB 
reset, IF masks out signals presented to the INTR pin. It has no effect on NMI, on processorni^^l^ 
exceptions, or on software signals (INT and INTO). i- i: ■ j , ■ t ■ i • : 

To<set IF, use the STI instnicti9n.(^i^!ll,l#iit^0ftj^#|-/|i|lji8^ use GLI (DIS>W8tE)= 



Interrupt Descriptor Table 

The IDT associates each interrupt identifier with a descriptor for the instructions that prbd^Hhe 
assggj^^ed.gVjeiit. The IDJ is similar to the GDT and LDTs but is different in two ixaj^T^vii fs^^/sfstA* 

processor references the IDT only as the result of an interrupt. 

• The only descriptors permitted in the IDT are three kinds of gate descriptors: task gates, interrupt 
gates, and trap gates (descriptor t5^^' '$--7, iies|)fectively). 

The IDT may dwell at any location in memory. The processor locates the IDT via the IDT register. 
The operating system uses the instruction LIDT (load IDT) to set the IDT register. The instruction 
SIDT (store IDT) reads the contents of the IDT register. There can be only one IDT, but the operating 
system can use the LIDT instruction to substitute another array of gate descriptors. 



Interrupt Tasks and Interrupt^iOcedttrAe- . C - ... 

fe response to an event, the processor interrupts the currently executing task and begins executing the 
instructions identified by the IDT gate descriptor that is associated with the event. The instructions 
that execute as the result of the event may either be 

• A task other than the current task 

• A procedure within the current task 

i "-. 

If the descriptor indexed by the interrupt identifier is a task gate, which points to a task state segment, 
then the processor causes a task switch. Figure 6-1 illustrates the links that identify the interrupt task. 
Copter '4idi8cuss<^. the ;Tt^han^a^#ss@ei^ and considers thl^ imp^.^t 

hardware task switching has on the operating system's task scheduler. 

If the descriptor indexed by the interrupt identifier is either an interrupt gate or a trap gate (which 
point to executable segments), then no task switch occurs. Instead the processor behaves similarly to 
the way it would if the current task had called the indicated procedure via a call gate. Figure 6-2 
illustrates the links that identify the interrupt procedure. The iAPX 286 protection mechanism requires 
either that the target segment have a privilege level numerically less than or equal to CPL or that the 
targetisepne%t.:beiconfornuqg. . iLf one of these conditions is true, then the^wdicated procedure .begins 
■mBemlam$.ik ttevcusrent ta^ ^^^^jor inecfaamcal differeiice betwefa9»fll«ftklag a pro^eA^fe^ an 
MKteetui^aBd'irondcmg bymil^d;L'4K'that; with an interrupt, the processor pushes the flag word onto 
tbe &^d( Mvthe invoked jw o tedm e i before the return address (as illustrated in figure 6-3) and clears 
the single-step flag (TF). 
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Figure 6-1. Interrupt Vectoring forJTa^lcs 
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Figure 6-2. Interrupt y^^Mlpi^^Wo^li^H ' '"T"^ 

Note that if an interrupt occurs while a privilege-level (PL-0) procedure is i^^tinjg. afl afteflipt tb 
transfer to a less privileged level violates prqteeticm iTiles; (The saroe pW)t»(^iSA^rtil6s apply as for a 
CM-L to a Ibss piivil^d ^|mi^t.3'!!tf'|ft(j#ral it- iS- tm^ssiMe fe interrupt occurs; 

t*erefore, it is equally lmpossifete %%toid'a proteetioii'viblM procedure has 

aih interrupt gate bf trap gate til thfe IDT. ' " ' ; - i , . - i 
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j Figure 6-3. Interrupt Procedure's Stacjk 

What is'the difference between air jnterroptinrwintamipt gate and an interrupt via a trap gate? Iri 
the case of an interrupt gate, the processor automatically disables interrupts before transferring control 
to the interrupt procedure; therefore, an interrupt gate is normally used with external interrupts. Iii 

the case of a trap gate, the processor does not disable interrupts; therefore, trap gates art normally 
used with processor-detected exception conditions, which are also known as "traps." 

The IRET instruction returns control from an interrupt regardless of whether a task gate, interrupt 
gate, or trap gate is used to enter the iDterrupt handler. In all cases, executing IRET restores IF to its 
value before the interrupt. Ill tibe-ea9^^^#i^4aMn;tpt pfoceiiare,-th&-proeesa9r restores flags from th^ 
Itack; in the case of an inter«p4ta^t»JEi8BJEteJwterruptiBd task's TSS. 

The difference in speed betweeq^hanBTing an event by a task gate versus by an interrupt or trap gate 
is not great, as table 6-1 illustrates. , i 



OPERATING SYSTEM pp^spi^y;!"]^^ , ;~7^~~,:^ — ' 

Given the number of hardware features that automate event handling, you might wonder what is left 
for the operating system to do. In fact, for static systems in which interrupt tasks do not call on operat- 
ing system functions and in which there is no need to change the IDT, the operating system need not 
concern itself with interrupts. Few apphcations axe so simple, however. The foUovving sections dis^s 
some extensions to the processor's event-handling features tfa;tt^^imiiyiiindQuseful in your operftt^ 
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TaDiee-1. iniernipi msponM iime 



Operation 


ResponseTlnieOn number lorteMtokcyelM) 1 


Task 

Gate 


Interrupt or 
Trap Gate 
(to different PL) 


flafdware in&rrupt 
' processing ' ^ 


167 


78 


Save regisiltrs 
PUSHA' 
PUSH DS 
PUSH ES 


taskswitt*-'^ • 


3 


Initialize registers 
MOV AX.SEG item-1 
MOV DS.AX 
MOV AX.SEG item-2 

MOV ES.AX 


UUlie uy 

task switch 


■ 17 

2 
17 


Total Clocks 


167 

' ^- ' -i i 


139 



system. The common goal in all these extensions is to structure the software so that, when an event 
occurs, the hardware can handle interrupt administration chores automatically within the efficiency 
and protection requirements of the applldatidfi. ' j'^ ' • • i- . ' 

Manage IDT „ j , , 

Many applications require the /^bility to change the association between an event and the procedure or 
task associated with it. Even relatively static systems require this ability if interrupt procedures and 
interrupt tasks are not loaded until after system initialization. Only PL-0 procedures can effect run- 
time changes to the IDT because the data-segment alias for the IDT should have PL 0. The techniques 
for changing the IDT are similar to fteteidready iUuStratfedsiiiklphaptCT aJtor ttoej GDT and LDTs. 

■ i. O'- j'icr.L'tiia AP?lJ< -jril rljirfw rri voiloq l'";:ri iiiji,, . . n-. ' 

Switeh'SeiiediiiingMod«8^ ' i ' i --.it^- ; v: . 

' •••• • ' • ■ •'• 'iitii. Jtii..i If!/ • : . ;;,''iv • ' • ■<■ 

An application majhincl^de tasks that run soi|ffj||^(ji&is^p^|^|^^^^jQ||;»)jj^es 
under the supervision of the operating system's scbemilcr. Bxampes of such situations include the 
foltoswiag: p , u .;: , , 

. '. ' • . i . . 

• An interrupt task calls on operating system services that might force the task to wait (for example, 
RECEIVE31ESSAGE). ^ ^ - . » : i 

• The task loader (in a dynamicispteinj does not distinguish between interrupt tasks and regular 
tasks, leaving it up to the task itsclftt® request that the operating system attach it to an interrupt. 
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If such situations can arise, the ajf^faf^^ system must 

Keep track of whether a task ift%);]iaidware-scheduled mode or in software-scheduled mode \ 
*' ihrSWlSe services to switch a HsFMCweff^^^^SiKl^led and software-scheduled mode ' 

Note, however, that an interrupt task that is in software-scheduled mode cannot service interrupts. If 
it is possible for further interrupts of the same type to occur during the time the interrupt task is 
software-scheduled, then switching to software-scheduled mode is not such a good idea. An alternative 
strategy is to allocate interrupt-servicing duties among two or more tasks; one hardware-scheduled and 
the others software-scheduled. The hardware-scheduled task responds to the interrupt and invokes one 
of the software-scheduled tasks through a mechanism such as message-passing as discussed in 
Chapter S. If there are any delays in servicing that interrupt,; it is one of the softwajr^^^t^uled tasks 
that waits, not ithe hardware-sch4duled tas;];. I ,^ i u | 

^ I i ,'. 'i'^ ; 

( i 



Manage Interrupt Control^r ^^x) 



Intel's 8259A Programmable Interrupt Controller (PIC) is key system resource in a multitasking system.| 
The 8259A PIC is a flexible device that gives the main processor the ability to service up to 64 external 
events via the processor's single INTR pin. The 8259A PIC gives software control over such critical 
parameters as the relative priorities among interrupts and the means for acknowledging interrupts.. 
Correct operation of the system requires proper use of the interrupt controller. For the operating system 
to manage this critical resource is only consistent with the protection features of the iAPX 286. 

At system initialization the operating system may initialize the 8259A PIC according to system config- 
uration and the nee(is of tfie application. Initialization may include 

• Setting the 8259A to operate in iAPX86 mode 

• Settiag up master/slave relati<msMps vihm th^ iial#wai« C(ni^iifati(m includes multiple PICs 

• %ecifying whether interrupts are triggered by edge or by level ansM 

• Setting interrupt priority mode: rotating or masked 

^' l&etermining whether priority is fully nested (if priority is set by masking) 

• Determining whether interrupts are acknowledged automatically or by explicit EOI command 

Refer to the Component Data Catalog for details of these and other features of the 8259A PIC. 

M you cheese an interrupt policy in which the 8259A automatically determines interrupt priority and 
antMatically acknowledges interrupts, then there may be no seed, after initialization, for either the 
operatii^ system or interrupt tasks and procedures to deal with the 8259A. If, on the other hand, you 
choose a dynamically changing priority scheme (whether by specific rotation or by mask commands) 
or explicit end-of-interrupt commands, then you must also choose whether run-time control of the 8259A 
is the responsibility of the interrupt tasks and procedures or of the operating system. 

For the operating system to maintain run-time control over the 8259A PIC, it may provide a procedure 
mck as the following that applicaticnis ptipMS CMl, MiNd itf mmilk^ the IRET instruction. 

I'iitTOR.IHTERRllPr WrW~*'^^^^'^ .y]^ ' 

ifil,.ji:j: > - l iiif-;' i . S w 1 ,t o h, .to t B 9 k o n b a.c ke- iii nsk ' I ,!..?:' .HT • 
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RET ; Return to application procedure 

WflIT_FOR_INTERRUPT EN DP 

The operating system executes the IRET instruction within WAIT_FOR_INTERRUPT. 
WAITJFOR_INTERRUPT would need to run as a privileged procedure within the calling task. With 
this approach, the operating system has control just before the task begins to wait for an interrupt as 
well as when the task begins to execute after the interrupt occurs. The operating system then has the 
opportunity to send interrupt masks, end-of-interrupt commands, and specific priority rotation 
commands, as appropriate for the application. 

:■ . -i ■ ,. , . ■ ■ 



Provide Task-Level Interrupt Proceducf^a, ,:bk/ / r 

GDT interrupt procedures (i.e., those invoked via interrupt gates and trap gates in the IDT that point 
to ©jLecutablersegment descriptors in Jhe QDT^ . provide 4 ^abal mechanism for a task to react to 
eveets. The mejchst^m is global tesrase ^SMmm^abiiSlm^^'^^mkaa^itispp&ts^ of the 
ta^ is ±e systenx.JFw example, soppose%<jDJiirfc»niipt'pnsiqBitamfaaO)^ ?«|ivide errolif'tBxeep> 
tion. Then, a divide error in task A is handled by thfc sameprbct^fire fts a dlfiae erro* in task B because 
there is just one gate for divide errors. There is often a need, however, for one task to take different 
action than that taken by other tasks. For example, task A may need to terminate in case of a divide 
6rft)F$iwhile ^idc- Biffi9cy need toicontinue. i' 
I r- . ■ _ 1 r I ■ - : ■ : ■ - 

INTERRUPT DISTRIBUTION 

The software system designer has a choice of mechanisms that make it possible for different tasks to 
jhave different interrupt procedures for a given interrupt type 

i. LDT-based interrupt procedures ^ 

jZ. An interrupt distributor 

You must deploy alternative 1 carefully. If a trap or interrupt gate in the IDT contaSis a selector for 
an LDT slot, thp<i there must be a^system-wide convention that every LQT will have.an appropriate 
descriptor in that slot. When the ii|temiptoc4irs, the processor u|es the ^>DT of the current task tq 
oca^e the interrupt procedure. ' — j ^ . ,^ 

Alternative 2 demands less from convention, but more from the operating system and the processor. 
JVith this approach, each task has (in the task database) a table that is its own private analog of the 
iDT. The operating system supplies a GDT interrupt procedure that merely indexes the current task's 
handler table to find a pointer to the appropriate handler procedure. If the task does not supply an 
intedhipt procedure for a specific inierrupt, thd operating system can invol^a. default procedure. 

CONFORMING INTERRUPT PROCEDURES 

jpor certain interrupt procedures (for example, a divide-error exception handler that substitutes a fixed 
jiralue for the quotient), the appropriate privilege level at which to run the interrupt pfocedure is the 
^me as that of the interrupted procedure. In these cases, the interrupt procedure can be placed in a 
bonTbitting segment. Fen- interrB{»t-pi»cedui«s-ia.coB£MBiii^-«egmeotSr^6 -processor automatically 
sets CPL to the DPL of the segttent>e@iftainii9g'the^b^ple)} T^i&^0Aiie. Note, however, that this 
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technique does not apply to prc^Bbaiy all!l^% iL^^t^nhiV distribution procedure (because \Mc 
distribution procedure always runs at PL 0). , . . , - 

O f > T T I n ■> ' , J [ 'M 

"OUTWARD CALL" 



An ftpMication may contain stttae iat^fUfit proesdtores that idiou!d'RUi at a fixed privilege level that is 
t^iillfH^ ai^oJ qo ^HT -?iu530 Jcjtnwlni ortl laile sti/osxa oJ ani; ■ : nai^ " ss slaw 

fl'iilfio'; •> • ■ .■» • SaF. . > br & ff : .- • f.o ) "^UTi 9 J 1 fa 't ? .2:^"rin ifi:-— i.-- • .••■r.MtciqrjC 

The processor, on the other hand, prevents calls from PL n to PL m if n<m. For privilege-checking 
purposes the processor treats interrupts to procedures as calls. It is a privilege violation if the interrupt 
procedure resides in a segment that has a DPL numerically greater than that of the interrupted proce- 
dure. Since interrupts may occur at arbitrary times, it is possible for CPL to be less than the DPL of 
the interrupt procedure, which would be an excepSat'.**"*'""^ '"^ v. »->.:. > otwwf . 



A similar problem results when an interrupt distribution procedure (whjch runs at PL 0) attempts 
call a less privileged procedure identffied in the task's interrupt faitt^labtatble: The problem MMl^ 
eq«ib.if the interrupt distributwiatl«n|A»^<ftii»d!iAeiai«»^ procedure by u»ngvi^ 

iatl»i«^<lid^^«cedure's (ISil^!«s-lhBHI(!kamS^Bmim^s0M^ handle. A'^' noi 

The operating system can employ the shadow task strategy to overcome this contradiction. Figure 6-4 
outlines the shadow task strategy for invoking a lesser-privileged procedure from PL 0. Only a PL-0 



1' , >-_«irEimuPT 

ID 



Mil il 'jiuti:--'jv: 
'[ b'.'j-r.-r! .'I • 
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procedure such as the interrupt distribution procedure described previously can implement this mecha- 
nism. Instead of calling the handler procedure (which could be a privilege violation), the operating 
system's interrupt procedure 

• Creates a shadow task containing the handler procedure 

• Sets the CS and IP fields of the shadow task's TSS to the entry point of the handler procedure 

• Calls the shadow task 

An IRET instruction in the interrupt handler procedure returns control to the interrupt distributor 
procedure in the main task. 

Creating a shadow task involves simply allocating space for the new TSS and initializing it. Setting the 
LDT field of the new TSS to the same value as in the main task's TSS lets the shadow task have access 
to all the same segments as the main task, including the segment containing the handler procedure. 
The operating system may create the shadow task either at the time the main task is created or dynam- 
ically, at the time the interrupt occurs. 



Provide Software Signals 

In some applications there is a need for one task to send a signal to another task that is not waiting for 
the signal. The "quit" signal in an interactive system is an example. For the target task to respond 
quickly to the signal, the signal must trigger some form of interrupt mechanism. The mechanisms 
described previously for private interrupt procedures have the appropriate features: each task can define 
the action to take upon receipt of the signal, and the signal handler can run at a restricted privilege 
level. Additional components needed to implement software signals include 

• Extended task handler table with entries for each possible software signal 

• Operating system procedure that any task can call to send a signal to another task 

A software signalling mechanism is also a convenient way for the operating system to signal tasks. This 
method is particularly suited to 

• Reporting exception conditions detected by the operating system 

• Giving a task the chance to put its affairs in order before the operating system terroinates it. 
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Handling Exception Conditions 
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CHAPTER 7 
HANDLING EXCEPTION CONDITIONS 

When the processor recognizes a condition that it cannot handle, an exeepMmiCf>Hdition, 9psi9^mg 
system or applications software must temporarily take control and dispose of the condition. Exception 
conditions are also known as "faults." . ■ ■ . ■ .• ^ :■;■ 

t , , . ■ 

FAULT MECHANISM ^„ t 

The processor reports an exception condition by causing one of a predefined set of interrupts; one 
interrupt vector is associated with each exception condition that the processor recognizes. As with any 
interrupt, either a procedure or a task can field a fault. Faults resemble other interrupts, but they 
differ in two significant ways: 

■■I'.'f. --J ■ . "> .ni'j ..t •us,: li : . ' ■ J- 1 

» You cannpt disable a fault. • : 

• For certain faults, the processor pushes an error code onto the stack of the fault handler (whether 
procedure or task) to help with recovery. 



FAULT RECOVERY 

When a fault occurs, the fault handler has three possible ways of dealing with the exception: ''■ ' 

• Ignore it and continue execution of the task. 

• Fix the problem and retry the faulting instruction. ^.^ , » 

• Kill the faulting task. 

Ignoring an exception is not generally advisable. Killing a task is sometimes unavoidable, but, for 
critical tasks, the handler should make every effort to recover from the exception. In many cases, the 
iAPX 286 helps the exception handler identify the faulting instruction and the conditions that caused 
the fault. 



Locating the Faulting Instruction 

Usually, a fault handler can lockte the faulting instruction either via the return pointer on the stack (if 
the exception handlpr is an interrupt procedure) or via the 4P stored in the TSS of the faulting task (if 
the exception han^r is an interrupt task). This stored value of the IP is used to i^tum control to the 
interrupted task, lUe- cXcej^mit:^SS^ilSS^^ the faulting 

instruction. TTiere are three cases to consider: 

• The stored IP value points to the location of the faulting instruction (including all prefixes). This is 
' the normal case. " ' m-.t oT*iiii«?^?» ■ • ■ , • 

• The stored IP value points to the location of the next instruction. 

• The stored IP value is unrelated to the fault. This occurs, for example, with 80287 instructions 
(which execute in paraUel 3ivith.8Q28£iBSlIl^tos)U QtJKto discovers a fault 
while attempting to handle ani<pJgrBal. int«f^|,, -,v-t .;• s 3v.. j>n. 
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Code 



With exceptions that may relate to a specific segment, the processor pushes an error code onto the 
staclc of the exception handler (whether procedure or task). Figure 7-1 illustrates the error code. The 
format of the error code resembles that of a selector. However, instead of an RPL field, the error code 
dintains two one-bit items: 

M lite fvocmor sets the EX (exler^) Mt #llen the fault kl^'^M^Fesult from an mdUkfW 
&m task. Occurrence of this ccmdition generally indicates a "system" iHX)blem as opposed to an 
"application software" problem. 

• The processor sets the I (IDT) bit if the index portion of the error code refers to a gate descriptor 
in the IDT. When the I bit is set, the handler can ignore the TI bit. If the I bit is reset, then the TI 
" bit lagfiWffis either the'<^%%STJI¥, just as irti 9^^» nnim-,-,.-. . ■ , 

The index field identifies the descriptor associated with the exception (if any). 



In some cases the error code on the stack is null, in which case all bits in the word are zero. For some 
faults, the handler can gain additional inforMdm akm^ tbe fault by d^hnining whetHei- th^'^of 

Q@deJS null. ' : J:.'.?,"' ;.!n;- i:L'f.j TMi r^f: ^^ri'.'uq VJiiiSaaiq t. -.f-.IO-i • 

APPLICATION INTERFACE 

Since sonne of the actions appropriate for exception conditions depend on the requirements of ii^vid- 
ual applic!^ip%:^]30grams, the, ^i?iat^,systejaj may need to prowde an rS^l^cation interface 
Inception handling system. Chapter 6 dismisses mechanisms for doing so. 



EXCEPTION CONDITIONS 



The action appropriate to each type of exception depends both on the type of exception and the needs 
of th6 applic&Siid This sel6iiai>^rovides details for ea&h type df exception. Seme -^/ the exception 
I iU^liBlltified bfm«^^</lm&cteT mnemoiuc that s(Ane other Intel tili^tdre uses. 



■i9M«nn3 Of tsttta »o-<H 



11 ii.fi' ■ 1 'Jit] 



1 IF DESCRIPTOR IS IN IDT 



EX = IF EXCEPTION OETECTEO DURING 
EVENT EXTERNAL TO TASK 



i'.ai . 
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Interrupt — Divide Error • v. : - f anijioui i>rii ;-ju:r:,- i .i . i 




This exception may occur during DIV (unsigned divide) and IDIV (integer divide) instructions^ The 
processor causes a divide-error exception in case of division by zero or quotient overflow. 

A divide-error handler might, for example, replace the quotient with a pre^termined value and permit 
the faulting task to continue. TTie return pointer indicates the first byi^W%i ihstrtictiaB; sb the 
handler must increment the return pointer before returning. 



The processor causes a single step exception at the end of every instruction when the TF (trap flag) is 
set. When the processor invokes any intemipt procedure, it ^ves the flags and lesets the TF so that 
the exception handler does not cause a single-step exc^>d<m. Bxeei^iae IRET at the end of the excep- 



tion handler restores TF. " ' ' ' 

The exception handler for this exception typically belongs to a debugging system. Single stepping is a 
valuable debugging tool. It allows the exception handler to act as a "window" into the system through 
which you can observe task operation i;isti;uction by ii;istruction. A single-step handler may, for example, 
display register contents, the value of the instruction pointer| key variables, etc., as they change after 
each instruction. 



The single-rst^pei^ptj^ handler should take care, however, not to violate the system's protection goals 
by its actions. To protect the operating system from the debugging activities of an applications 
programmer, the debugger should not give access to the more privileged levels. The debugger can 
check, either before or after each instruction, whether the instruction causes a control transfer to a 
prohibited level. After such a transfer, the return pointer identifies the next instruction in an accessible 
segment. The debugjger can set a breakpoint at that instruction and suspend sin^e stepping, until the 
breakpoint trap occurs. 

Interrupt 3 — Breakpoint 

The INT 3 instruction causes this exception. The INT 3 instruction is one byte long, which makes it 
easy to insert a breakpoint anywhere in an executable segment. The operating system or a debugging 
subsystem can use a daiBj-isegnient alias for an executable segment to place an INT 3 instruction anyplace 
where it is convenient to> arrest normal execution $o that scnne mrt of special processing can be perfcntu^d. 
Debuggers typically use breakpoints as a w&f #^teji^g r^islers, t^riables, etc., at cMml ^itfts 
in a task. 

The saved IP value points to the next instruction. If a debugger has replaced a planted breakpc^iqt.wi^ 
a valid opcode, it must subtract one from the saved IP value before returning. . .- ■ 



Interrupt 4 — Overflow 

This exception occurs when the processor encounters an INTO instruction and the OF (overflow) flag 
is set. Since signed arithmetic and unsigned arithmetic both use the same arithmetic instructions, the 
processor can not tell which is intended and therefore does not cause an overflow exception. Instead it 
merely sets OF when the results, if interpreted as signed numbers, would be out of range. When doing 
arithmetic on signed operands, careful programmers and compilers either test OF directly or use the 
INTO instruction- - ' 'S.'Ok srti sairr-v r ,■ 



Interrupt 1 ^Single Step 




T 
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An exception handler usually terminates the faulting task; however, in some applications it is feasible 

to place a "maximum value" in the receiving operand and permit the task to continue. The return 
pointer indicates the next instruction. .>.,.,.. 

yjjtQr/iJipt 5t— Bound PNck ■,,<■ h-; ^ jiioq muwi ©rfx wn- jbI 

This exception occurs when the processor, while executing a BOUND instruction, finds that the operand 
exceeds the specified limits. This condition usually indicates a programming error. The safest action 
for the handler is to terminate the faulting task. In some applications, however, it is feasible to '^a'dlBtt^ 
the erroneous operand. The return pointer points to the beginning of the faulting instruction. 

Interrupt 6 — Undefined Opcode (UO) ui . > 

This exceptiori'Sc^rs whdii PB^^ssor detects an invalid operation ca^ M tWi tTiMivM&a^ s&^0. 
Such an i^tdijpga may oi^^mr example 
data in "ah'^raedtttable segnMIE'^fhis eicepti 



Such an i^tdiptga iqay oi^i^^mr example, if a programmer aMts^BSi^^^usiii a. 
ata in "ah'^raedtttable segnM1E'*fhis eicep^^^ iloid* 

• The first byte of the instruction is completely invalid; for example, 64H. 

• The first byte of the instruction indicates a two-byte opcode, but the second byte is invalid; for 
example, OFH followed' by OFFH. 



• One of the i^^iifapds crf.t}ie instruction is not valid for use with the opc^^^ I , ^sriit-. M^da 

^'The opcode extension in the second byte of an instruction contains a value that is inval^'ti^^^fiii 

• with the opcode; for example, opcode 0F6H with xxOOlxXxB in the second byte. """gaz 

• The opcode requires a memo^ op^wi, but tie opmsd aetii^y iat^cates a register, for example, 
LGDT AX. 

The offending opcode is in'^lid, so the handler should not restart the instruction. 

You can use this exception to implement extensions^ the iAPX 28^ instroction set. The exception 
handler would inter{>^t «4t^fi9^1nstnic^^ 



before returning. " '.--^^-Jic - jokj vc wjuvj^;, i»iu iuh /rjj b ' 



MItorrupt 7— Processor Extetrif^li^^;^^ 

iis ^«»ption occurs in either of two condMions: 



• The processor encounters an ESC (escape) instruction, and the EM (emulate) bit of the machine 
status word (MSW) is set. 

• The processor encounters a WAIT instruction, and both the MP (mathj present) ayripi ^&St 
switched) bits ofthe MSW are set. „...„, ' . . , „ . , ■ " - ■' •mfijwi^ 

adl 58U t:> -li-. ^r:. ■<- ^ isrfib *;i3liqmna bne nsnmungoiq lulnsn .ybnoit)' •• i 'lifnt 

iMer to Chapter 12 for details concerning tile 80287 Numerics Processor Extension. " -'i 
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This exception occurs when the processor deteets afl esie^plfew^^te' ti^feg to invoke the han«fler for a 
prior exception, for example: 

• The code segment containing the exception handler is marked "not present." 

• Invoking the exception handler causes a stack to overflow. 

The processor pushes a null error code onto the stack. If this or any other action while invoking the 
double-fault handler causes an additional fault, the processor shuts down. To avoid the catastophe of a 
shut-down, the double-fault handler must be a separate task (so that pushing the error code does not 
cause a stack fault) and must always be present (so that invoking it does not cause a "not present" 
fault). 

I^ep^very is sometimes possible by eliminating the cause of the second exception and re-qxecj^ting the 
fauldng instruction so that the original fault can be handled appropriately. The greatest ditocultjr lies 
in identifying the cause of the second exception. Often, however, a double-fault condition indicates a 
serious error, and the faulting task should be terminated. ' ' ' 

Interrupts — Processor Extension Sdgmdrit Overruff' ' ' 

This exception <mii$ when a fiieffi^l^^ipid of an 80287 instruction hl#£f<^iKtent-liiidt 'i4dlatidii. 
Since the 80287 executes in parallel with the 80286,^ 'tbe e^fr«i^ W'tM^4eX<^tion may n6t )«Me 
directly to the instruction stream being executed by the current task. A task switch may have occurred 
since the 80287 began executing the instruction. Even if the interrup^dst8$k is the correct task, its IP 
way have been advanced by several instructions beyond the 80287 instfoetiOn. Refer to Chapter 12 for 
tiore MormatidB afoout this exeeption. 

Interrupt 10— InvaUd TSS (TS) ' 

This exception occurs when the processor detects any of the following abnormalities in a TSS: 

1 . The value of the limit field 6f m> dmAptttf ^&l^^W&'^> VS^HISniA' (diseovered during a task 
switch). ' I • f -.laniq ;-.ft" iuj ^/.j-s/aL • 

2. the LDT indicated in the tSS is invalid or ftol'^Weair^tasI^ switch). Note that a null LDt 
selector does not cause an exception during a task switch. 

3. One of the segment register fields (SS, CS, DS, or ES) in the TSS is invalid (task switch). 

4. One of the privileged-stack selectors is invalid (interlevel CALL). 

5. The back-link selector is invalid (intertask IRET). ' ' 

This exception does not occur when a segment-r^k^Pfield or the back link is marked "not present" 
but is otherwise valid. A "not present" exception occurs in this case. If, djiring .an interievel CALL, 
a ikrivilegedikack selector iff the TSS points to a descriptor ma^^''**i<k''pisent," iliart k stack 
ex<;eiptiori'bcCurs.'' '■ ■ ■ -- i^ ■ .: . .-.'-i <'u i^au.: inv. 

The handler for this exception must be a separate task, invoked via a task gate in the IDT. The proces- 
sor pushes an error code onto the stack of the handler. The error code either identifies the faulty 
TSS (case I) or contains the faulty selector from the TSS (cases 2-5). The instruction causing the 
fault can be restarted. An IRET at the end of the exception handler causes the faulting instruction to 
execute again. ; ; 
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A few of the conditions that can cause this exception are recoverable. If the system incorporates virtual 
memory, the solution for a not present LDT may be to bring it in from virtual store. In the case of an 
invalid back-link, you can niake the assumption that the NT flag was set by mistake, give control to 
the scheduler, and hope.... rvi.,, - i , . ^t.i;!) 

Interrupt 11 — Segment Not Present (NP) 

7biSsil9^!eit«im occurs when t)i©,pj(}§^pij^66^tJ^^.>P?e&Wti^>M of „a descriptor is reset. Uimm 

'■)■ ■:■ -ii -; , -r.r, :■ <.■ ■'.' : , ■ . 

• While loading the CS, DS, or ES registers, but not while loading the SS register (a stack' flaMit 
occurs in that case). 

• While loading the LDT register with an LLDT instruction, but not while loading the LDT register 
during a task switch operation (the "invalid TSS" fault occurs in that case). 

• WMle attempting to use a gate that is mm1e^J^jg|r:^p||y^(,2 licLi ^niih, . . , ^ j; .1. : -tioi-.-.-: 

An operatting system typically uses the "not pvse^" mme^ii&ea to mf^lement a virtual memory system. 
Refer to Chapter 9 for more inf(mqiyfl^!lfji||Wi|ij|^^ TOee . . . 9 ■<,. iieJnl 

The proc^sor pushes an error code onto the stack of the exception handler. The error code contains 
the selector of the descriptor that is marked "not present." 

A "not present" indication in a gate descriptor usually has special significance for the operating system. 
For gates in the IDT, the present bit msf$ie^ite!ss a sign that the interrupt task is in software scheduled 
pode md temporarily unable to service m interrupt. If an intem^t^aPBr^dli tlus .c«se, theri^iWpdite 
m tsma either in the device that geam&tes the interrupt cxr in the handling of the Interrupt Mask 
Register of the 8259A PIC. (Refer to Chapter 6 for more information on interrupt handling). For gates 
in the GOT or LDTs, the present bit may serve to signal an unresolved linkage. (Refer to Chapter 1 1 
^ information on binding.) 

The instruction that causes a "not present" fault is restartable (except in the case of a task switch). 
Execution of an IRET by the exception .handler causes the processor to execute the faulting instruction 
again. When the processor detects the "not present" exception while loading CS, DS, or ES during a 
^^s^i^^he exception^owurs_^uj jthe new task, and the return pointer points to the first instr^ctiop 

Interrupt 12-Stack Exception (SS) ,.,„,«i> bil«^ni . 



This exception occurs in ei^e| pf two general conditions: 



|j As a result of a limit violation in any operation that refers to the SS register. This includes stack- 
oriented instructions such as POP, PUSH, ENTER, and LEAVE as well as other memory refer- 
ences that implicitly use SS (for example, MOV AX,[BP+6] ). ENTER causes this exception when 
the stack is too small for^U^ij mdicated local variable sgace. Ab, interlevel CALL reff ranees t^yp 

,^:,sta6j^;a.$ta<jc>-}iihitexcip|a|v^ ! ' " ^ " ' ' / 

When attempting to load the SS register with a descriptor that is marked "not present" but is 
otherwise valid. This can occur in a task switch, an interlevel CALL, an interlevel return, or a MOV 
or POP instruction to SS. ; jou/s 
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The^ptocessoripusjigs an.«rror code on, the fl£ the ?xMpUon handler. .If the exception is due to a 
not-present stack segment or to overflow of the new stack during an interlevel CALL, the error code 
contains a selector to the segment in question (the exception handler can test the present bit in the 
descriptor to determine which exception has occurred); otherwise the error code is null. 

The instruction that causes a stack fault is usually restartable. Execution of an IRET by the exception 
handler causes the processor to execute the faulting instruction again. The one case that is not restart- 
able is a PUSHA or POPA intruction that attempts to wrap around the 64K boundaries of a stack 
segment. This condition is identified by,0n(?/ofj,tji6vys^lw fliFE|I>,iBfI[F^ OOOlH in the 

saved SP. 

.ntilrnso/^ .^irir no fioilfifniotni -jioiT, 1&T S ' -.i ■ ' 
When the processor detects a stack fault while loa^g SS during a task switch, the exception occurs 
in the new task, and the return pointer has the value that the IP fleld of the new TSS held at the time 
the task switch began. ; ;>Or)ic? -*ll V .: ; ■ 

When stack overflow causes the exception, the stack fault handler can increase the size of the stack 
segment (up to a maximum of 64K) and permit the faulting task to continue.. When the exception js 
due to a stack segment not being present, recovery action resembles tHat of the "not present" ^t^t 
handler. 



Interrupt 13 — General Protection Exception (GP) 

All protection violations that do not cause another exception cause a general protection exception. This 
includes (but is not limited to) 

• Exceeding segment limit when using^fiS^-feiJ.or C^ . — 

Exceeding segment limit when referencing a destripfor table 

Jumping to a data segment ^ 
Writing into a read-only segment or an executable segment 
Reading from an execute-only se^ent ' ! 

• Loading the SS register with a read-only descriptor (unless the selector COffi^s from th^ TSSduring 
a task switch, in which case a TSS exception occurs) vo; - . I r ; 

• Loading DS, ES, or SS with the ^escriptor tifa'^tem seginent ^ ' - " 

• Loading DS, ES, or SS with the 4escriptor1b^an executable segmf^J^ !| = 

• Loading CS (by means of a CALL, JMP. or interrupt) with the descriptor Of a data segment 

• Accessing_memory via DS or ES when it contains a null selector ' ' 
Switclring to a busy task j j ,i . :r [ 

> Violating privilege rules | ' i 

jxhe processor pu^es an error code into the S^^Mji handle -'s desciriptor cause4 

!the exception, the' error code contaiiu a selectoT'^^ii^escrip or; otheM^^iP^ dnot code is null. 

The return pointer points to the beginning of the faulting instruction. Recovery may be possible, but 
because programming errors cause most of the conditions leading to a general protection exception, 
recovery may not be worth theifonfaterecp ri r ed lo td« aii fy flteiaisag: ■ ■ • 

A string instruction (any variant of INS, OUTS, MOVS, STOS, SCAS, or CMPS) with a repeat prefix 
(REP, REPE, or REPNE) is not restartable if it causes a segment limit violation. Check whether SI 
or DI is near the segment limit. 
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Interrupt 16 — Processor Extension Error (MF) 

The 80286 cduses this exception when it detects a signal from the 80287 on the 80286's ERROR input 
pin. The 8028# tissts thi^1>te>'^^fy at the beginning of Certain floating'pc^l instructions and wfieta^ 
encounters a WAIT instruMM"'*hiIe the EM bit of ihe MSW is rseset (H^yfiatotioh). ^^mg;-: 



Refer to Chapter 12 for more information on this exception. 

iilBmipt 17 — Run-Time Exceptions 



Intel's rdrt-tifte su^pport i^$4r^ uses this interrupt to communicate exception j^ndftions regarding 

range checks and pit>cedttt^i^^{i^ oWlflbw. A{$pH(^tic^i^^ int^i-riipt foi' iar^Ri^i^ 

i^uroose ' ' ■'' •■^^-'^^fTi-jsin noti-iR nivuuai .in-jma stiior; ion ,■ 'm ■ ■ i- xtt Mfb 



RESTARTABILiTY SUIMIMARY 

Table 7-1 summarizes the information pertinent to restarting the faulting instruction. 



Table 7-1. Restart Conclitions 





Exception 


; R^rn Address 

Relative to 
Faulting instruction 


" i^lte&ie? 


Error 
Code? 





Divide error 


First byte 


Yes 


No 


1 


Single step 


Next instr. 


No 


No 


3 


Breal<poiirt 


Next instr. 




No 


4 


Overflow 


Next instr. 


No 


No 


5 


Bound check 


First byte 


Yes 


No 


6 


Undefined opcode 


First byte 


No 


No 


7 


Processor extension 


Unrelated 


Yes 


No 




not available. ■t.-);^-.,'. 5 








8 


Double fault 


First byte 


No 


Yes 








(always null) 


9 


Processor extension 


Unrelated 


No 


No 




segment overrun 








10 


Invalid TSS 


First byte 


Yes 


Yes 


11 


Segment not present 


First byte 


Yes 


Yes 


12 


Stack exception 


First byte 


Yes 


Yes 


13 


General protection 


First byte 


No 


Yes 


16 


Processor extension 


Unrelated 




No 




error ^ 

' muy 
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CHAPTER 8 
INPUT/OUTPUT 



Many of the concepts previously introduced in this book apply to the design of the I/O subsystem of 
an operating system; in addition, the iAPX ^6 has-Maeml IjMi&atures of Spesial interest. 

The functions typically performed by an I/O subsystem include 

• Centrally implementing and standardizing I/O logic so that all application programs can share it. 

• Providing a uniform, high-level interface by which application procedures can request I/O services 
(as a minimum, the functions READ and WRITE). A more so|)histicated system may need a full, 
file-oriented set of interfaces such as Intel's Universal Development Interface (UDI). 

• Administering device naming. Often this includes transforming logical device identifiers into physi- 
cal identifiers, so that applications that use the logical identifiers can maintain independence from 
physical devices. 

• Nfanaging use of memory ns^ttn^s for lyO.t^f^e^. . • . , 

• Managing sharing of physiealidevices. Often this reduces to giving one task exclusive use of dsvice 
(for example, a printer) until the task relinquishes it. With disk devices, tasks can usually ^harcr.the 

device as long as each uses a different set of disk addresses. A sophisticated database-management 
system may require unlimited disk sharing (the database system assumes responsibility for block- 
level synchronization, deadlock detection, and recovery). 

• Providing device-driver procedures to deal with the vagaries of various I /O devices. 

• Optimizing I/O efficiency. This might include any of these techniques: blocking, buffer pooling, 
automatic seek-ahead, reduction, pf 4isk arm iRoyeinefit. ■ ; ; ; , ^ ; . , . , , 

This discussion of I/O classifles physical 1/6 operations thus: 

• Direct I/O, in whicli the 80286 processor itself communicates directly with the peripheral device. 

Direct I/O breaks down further into 

a. Memory-mapped, in which I/O is triggered by processor instructions that reference certain 
memory locations. 

b. I/O-mapped, in which special I/O instructions cause the processor to do I/O. 

• Indirect I/O, in, which an external processor (such as the Intel 8089 I/O Processor) performs the 



1/0 AND PROTECTION 



The concept of protection as applied to I/O deals not only mH^t^^^pspf^sr^ in I/O opeiatipos 
but also with the right to execute I/O operations. ' - - ■ 




I/O Privilege Level (lOPL) 



You can limit to specific privilege levels the right to execute I/O and I/O-related instructions, lOPL 
(a two-bit field in the flag word) restricts a task's right to execute any of these instructions: 



IN 
INS 



input 

input string 
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OUT output 

OUTS output string , _ . , 

STI set interrupt flag (enable interrupts) " 

CLI clear interrupt flag (disable interrupts) 

LOCK lock bus 

'i • . . 

When interpreting any'^ il(»P«ltfMli3 instraetions, the processor compares CPBJfoCiPPL. Ifi'CPL 
exceeds lOPL, the processor causes a $misr^ p^otec^aa exception and does not carry out the 
instruction. .•jbl/^,*I?^ m»t»^fle o\l n« W bvrnf.-hv . uJariT 

Only a 'privilege-level (Pi^ procedure (i.e., the operating system) can chmggiJi(3SShfJ'Bit9ll$ivo 
instruction that explicitly affects lOPL; however, any of the operations that load the fl^ wgcd^gp^ in 
some cases, change lOPL. The only mechanisms for -changing the flag word are ' ' . 

- - . . ,., ,Jli/iv7 jf...Zu\^yi S:-j.' ' •■ i,n fil -.88) 

• A task switch 

• The POPF (pop flags) instruction * 

• IRET : b C >^f*I 

When CPL is greater than zero, the POPF instruction does not change lOPL, even though it changes 
'Other Ib^sia the flag wieM.- The processor issues no error indication wbw^'lhis .occurs. A^ki switch 
4baids:^e<i^f»0ffii thie Task State Segiarat (TSS). As tog as thei{^«wilbtgi^^^'^aei»»<i^^ 
data-segment- aliases for di6^ftS& ivaiMldmii^yim'pA^tpai^tSlKlm tbe ope^g^pmimit can 
change lOPL in the TSS. .■ . -NtA ' , ;v iU'f ■ -^-'^ t- -: — - ' ••.■'r:>_ 

For maximum protection, the procedures of an I/O subsystem that run in the calling task should run 
at a protection level numerically greater than the operating-system kernel but less than applications 
procedures. lOPL can then include the I/O subsystem but exclude applications procedures. Used this 
way, lOPL forces less privileged application procedures to call on I/O subs^Stefn pi-c(Cedi<i^|ff I/O 
functions, thereby giving the operating system control over rnany I/O operations. 

Tasks that deal primarily w^th I/0^M©^ce drivei^, for example) may have an lOPL value as great as 
Iflth^t^iihii case, all 'p^3£ftfH%l%it the tas^^^^ to I/O operations, yet all four privilege 

levels are available to protect the procedures of the task from one another. 



Controlling I/O Addresses 

Protection is incomplete if not applied to memory accesses by I/O operations. lOPL does not apply to 
memory-mapped I/O nor to interface with intelligent controllers (because none of the restricted 
instructions are used). The operating system designer must make ^Kcit^ provisions to control these 
I/O operations, either via the operating system or with the Builder. {/inn ■ r fM r\\ i 



Memory-mapped I/O is subject to the segment-level protection mechanism of the iAPX 286. A task 
can execute a memory-mapped I/O operation only if it has access to a descriptor for a data segment 
that contains ^e of the niemory addresses reserved for I/O. Giving a task descriptors for only the 
^/O nofi^ftlff iSlBr^es thit! it lias thfe ri^ - u/a.. oii. ao/ 

• The task cannot access I/O devices assigned to other tasks. 

• Within the task, I/O is restricted to those procedures wbosiB pMl^e level ^ jnunjerically less^tj^ 
or eqtml to the DPL of the I/O m&mty address segmMtt. 
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You can still take advantage of I/O memory address protection even though the I/O devices on the 
bus respond to 1/0 commands. A hardware address mapper can convert the processor's memory cycles 
for the I/O memory space into I/O cycles on the bus. The address mapper will not initiate a bus I/O 
cycle unless the memory operation passes the processor's protection checking. 

SOFTWARE ADDRESS CHECKWR^ /feWtTCOWV^lMBOir^''^ " ' ' 

With indirect I/O, the external controller accesses 1/0 buffers independently of the 80286. This presents 
a three-;fold problem to the oBe^tiiMfpi^BK) u, rn. frra," ^ 

• Memory access by the controller is not subject to the avtotnatic pf^ecli(Hi i^K^king of the 80286. 

• The controller (probably) uses "flat" addresses (i.e., addresses that are not relative to a base address). 

• , Tike addressing irange of t)^e..<^ntToU^r may got q^in^^ ^^iqpl^t^^y ,wMJba.t of the 80286. 

Tjjie flow of control for indirect I/O requMts mtwt pass.ltough operating-systep^roce^ur^ 9 
stJtMt the operating system ckh^'^^"*' ■•' ^> • ■>'^i''3 s ■ ' - ■ •• i ' • 

• Check memory addresses and privilege levels against information stored in the task's descriptors 

• Transform base-relative addresses to a flat format recognizable by the controller 

. '[I •• ■ ". - . iu ,(3-'(-;.-b : . " 1 

• ■ ■ - ' r ,M vsrr, j-ivivi. - 1. ,• 



l/0 AND MEMORY MANAGEMENT 

An I/O subsystem can place additional requirements on the operating system's memory vp^^^etlfor 
example: ' 

• r/O functions may iise certain dedicated memory locations (for example, the addresses used for 

memory-mapped I/O, and the communication blocks and buffers that external controllers expect 
to find a fixed locations). The memory manager must be aware of these locations and must not 
allocate them for other purpos^.; ■ ' " ■ • , " ' ' ' 

• When buffers for external controllers are allaeaMd dyitttnMsBj^-iiiddtessiag limitations of the 
controller may require the memory manager to find space within this ^rtion of memory that the 

controller can address. 

• Once it allocates a segment for the use of an external controller, the memory manager must not 
■ move, delete, or swap out the segment without cooperation from the controller. 



PARTITIONING I/O FUNCTIONS 

To (Jetermine how best to distribute I/O functions across tasks and privilege levels, you must consider 

• The opportunities for parallelism , . . , 

• The needs for synchronizafjp^. ,, • i -.- ' — . -i 

• The requirements for protection i 
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BequiE«mao^ for PafaJlelism and Synchronization uuV 

OThc requireiB^tK^fot pa8^epSKi3(«l»ainMQiH^ include injA^t)^ 

following: . ■ • -r ■-'-.r.^ssgofYq arf' -"'r- -"•♦-^ ' ^H-^ 

• The application procedure that requests a RE.^P dff^tion may run in parallel with the I/O subsys- 
tem until that procedure needs to refer^Milii^ |lW l i"<iftl>. #<W?t^l«W<4>5^IS»n< fj^xnmk Jf^imt^ 
the data arrives or an exception occurs. 

i« The proc^ttf^ thkt ren^aiStfera; WRITE operation can Usually rUii ifi"pi-§11ir'WSli Ihe I/O subsys- 
tem. Some applications require acknowlegement of the completion of a WRITE operation (in order, 
for example, to synchronize with a database recovery system), in which case that procedure must 

• wait until the ia^owl»dtiWii»iWSV«i- ' ' '-^^^^^ jn; vi . . -.M • 

• SEEK operations normally run in parallel with the requesting procedure. 

• The I/O device can always run in parallel with some task in a multitasking system, whether it be 
the task that requested the I/O operation or some other task that is not waiting for I/O. 

• In a simple I/O subsystem in which a device driver only manages one I/O operation at a tirne, the 
driver can simply wait until the device signals that the operation finishes. If the requesting proce- 
dure is blocked, the deyi^^^^^^|(|pfQ}y,'^vsxt,t^e^j^^)^^^^^^^jp intp.^ W%^e-^;^(^ii9l 
for that procedure. " "" ' 

• In a more sophisticated I/O subsystem (for example, one iii wfccifi a ifi^'inver liandfes more than 

one spindle and more than one task can share a disk device), greatest efficiency results only when 
device drivers run in parallel with I/O devices as well as with requesting procedures. An I/O- 
c(nnplete signal from a device may arrive when tke ^Dsms^. Amex is busy. 




Figure 8-1 explains the symbols used in a Petri net graph. Figures 8-2 and 8-3 use Petri net graphs to 
illustrate two approaches to synchronization between parts of an I/O subsystem. A horizontal line 
represents an event of interest that occurs only under certain conditions. Circles preceding an event 
rispresent^e conditions undbtikbieh the event can occur. Circles after an event represent the ^^}- 
tions that result from occurrenoe of tlie event. A dot inside a circle is called a token. A token rep^^enls 
a condition that is in effect. An event occurs if and only if there are to^^^f^ all its inp^t c^^<^^e!ii|. 
When an event occurs, tokens flow into all its output conditions. ' ' ' ' ' 

Figure 8-2 assumes the simple device driver mentioned previously and points out how such a driver can 
service only one task at a time. Figure 8-3 shows how a two-part driver can deal with more than one 
I/O request at a time (assuming. that the I/O device can do so as well). I/O requests from applications 
proceduresndliTO jUist A, M^HttM^upts drive part B. Not shown by the Petri net graphs is the fact 
that the two parts of the driver must share information about outstanding I /O requests. Both figures 
show simplified device drivers to highlight the interactions among parts of the I/O subsystem;, for 
example, a real device driy|^^^^4^^j^jqidtipl^jpliysi9al I/O,co!^^ 
and may retry I/O operations tit case of certain error indications froin the device. 



Requirements for Protection 

The requirements for protection in an IjfO m^^tystem. include (in addition to the protection considera- 
tions previously discussed) 

• Device aUoiSii^wi tablesiattd any other data used by the primary I/O interface procedures must be 
protecii^ fjpoai all but th<»e procedures privileged to do I/O, but must be available to every task in 
which the I/O interface procedures can run. 

• Only the device driver should have access to a device's control parameters (for example, head settling 
t^ae for a disk drive). noiJ-j-.-o ciq ., • (T • 
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» Only the operating system and'the I/O subsystem should use queues of buffers and I/O requests. 
• An application procedure must not use a fey |ii^t an I/O device is simultaneously iftsing. 

Implementation Alternatives 

If descriptors for data global to the I/O subsystem (such as device allocation tables) reside in the GDT 
)with DPL equal to the I/O privileie Ifevel, then I/O prcx^u^ eS^.ae^^s^hem regar^ss of what 

i , , I • 
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Figure 8-2. S^eftronlpation with Simple Device Driver 
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Figure 8-3. Synchronization with Two-Part Device Driver 
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task the I/O procedures run in. The I/O interface procedures (READ, WRITE, etc.) must have DPL 
equal to that of the global I/O data and therefore must have call gates at the privilege level of appli- 
cation procedures (PL 3). If these call gates reside in the LDTs of application tasks, then I/O interface 
procedures can be shared by (but limited to) those tasks that need them. The call gates can also reside 
in the GDT, where all tasks can access them. In either case the interface procedures run in the calling 
task. 

The possibilities for running device drivers in parallel with the calling task suggests that they be separate 
tasks. Such a separation also serves to protect applications and device drivers from one another, a 
definite advantage because inherent complexity and frequency of change tend to place device drivers 
among the least reliable of operating system functions. The I/O interface procedures have the respon- 
sibility for managing the details of communication between the calling task and the device drivers. 

You can implement a sophisticated device driver such as that illustrated in figure 8-3 as two cooper- 
ating tasks: one scheduled by interrupts via a task gate in the IDT, and the other scheduled by I/O 

requests via an operating-system mailbox facility. 

It is possible to implement device drivers as interrupt procedures that run within applications tasks. 
Such a structure is advantageous in these cases: 

• Efficiency of I/O is an overriding goal. 

• Interrupts may arrive when a driver is busy. 

The lack of protection inherent in such a structure becomes apparent, however, when you consider that 
the driver procedure that fields an I/O-complete interrupt may run as part of a task completely unrelated 
to the task that originally requested the I/O operation, and must run at PL 0. 

Viewing the possible implementations of buffers from the perspective of the iAPX 286 architecture, 

the most pertinent consideration is whether a segment contains just one buffer or several buffers. An 
approach that uses one segment per buffer has several advantages: 

• The protection mechanism of the iAPX 286 (working as it does on segment descriptors) focuses on 
each buffer individually. 

• The selector of a buffer segment serves as a convenient buffer identifier, fitting easily into the 

aliasing and mailbox schemes outlined in Chapter 5. 

You can avoid the potential GDT congestion that may result from having one segment (and therefore 
at least one segment descriptor) per buffer by storing buffer descriptors in LDTs. 

When tasks share buffers (as between an application task and one or more device-driver tasks), you 
have a choice between 

• Leaving the buffer at all times within the address spaces of all the sharing tasks 

• Transferring the buffer from the address space of one task into that of another 

The mailbox scheme outlined in Chapter 3 easily accomplishes the latter approach. This scheme has 
the advantage that the application task cannot use t&e Mfer at the same time as I/O is in progress. 
The "usage privilege level" (UPL), if set to lOPL, proddes additi(»ial protection by limiting mailbox 
access to I/O procedures. The application's requiremraifes fw I/O efficiency may, however, preclude 
use of mailboxes for this purpose. 
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CHAPTER 9 
VIRTUAL MEMORY 

The memory legitimately addressed by the tasks running on an iAPX 286 (the virtual memory) may 
exceed the actual memory available. You can use this capability to lower memory costs, substituting 
disk or other less expensive storage media for relatively expensive RAM. Virtual memory isolates 
prograinmers from the amount of real memiAY^ th'S'ii^^Uter 4;^eiri. The system designer can trade 
off pcrforman«» agdnst system jeosfc usit^setentiBtfl^sofe^^ , ' ^ . i • 

A system that supports virtual memory can be analyzed in terms of mechanisms and policies. The 
iAPX 286 has mechanisms that help your operating system manage the swapping of segments between 
RAM and less expensive memories. The operating system must implement additional mechanisms as 
well as policies for efficient use of these mechanisms in a specific application. 



HARDWARE MECHANISMS 

The 80286 provides the essential hardware mechanisms without which virtual memory systems would 
not be possible. The segment is the basic unit of the virtual-memory scheme, just as it is the basic 
unit of the real-memory scheme. In each segment descriptor, the iAPX 286 architecture provides an 
accessed bit and a present bit to aid the operating system in simulating the virtual memory space with 
available RAM. i .'.-.iv /ii n . .i 



Accessed Bit 

Every descriptor for an executable ses^^n^ or dat^ segrn^t bii^^a,eieee^se4 /l;^^ signifi- 
cant bit position of the access rights oyte. Each tune a task loads s^m^nt register with a .segment 
descriptor, the processor automatically sets the accessed bit in that descriptor. The processor does not 
automatically reset the accessed bit; software must explicitly write a zero into the accessed bit. The 
accessed bit has a dual function in virtual memory manageni^ent:^ .^ ^ 

• By testing and then resetting the accessed bit at regular intervals, the virtual-memory manager can 
measure how frequently the segment is being accessed. 

• For writable data segments, the accessed bit (when set) indicates that the segment may have been 
changed. 



Present Bit 

Every segment descriptor has a present flag in the high-order bit position of the access-rights byte. The 
processor automatically tests this bit as it loads segment registers. If the present bit is reset, the proces- 
sor causes a trap. Which trap depends on the ciicumstances: < 

• . JJTrap 11 (Segment not Present) occurs when loading the CS, DS, or ES register with a not-present 

segment dps<;iiptor, when switching to a not-present TS^, wjtien loading the Task Register by means 
of the LTR insiruction with a not-present TSS descriptor, or when loading the LDT register with a 

not-present LDT descriptor. 

• Trap 1 1 also occurs when loading CS with a gate descriptor that is marked "not present." This 
condition dora not necessarily me^ that a segment is not ^esent, however. The operating system 
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may attach other meaning to the present bit of gate descriptors. Refer to the section on load-time 
binding in Chapter 1 1 for an example of an alternate use for the pp^ift bit in gate descriptors. 

• Trap 12 (Stack Exception) occurs when loading the SS register with a not-present descriptor. The 
exception handler can distinguish this condition from other stack exceptions by examining the access 
rights byte of the descriptor selected by the error code. 

• Trap 10 (Invalid TSS) occurs when switching to a TSS that points to a not-present LDT. The 
exception handler can distinguish this from other "invalid TSS" conditions by examining the access 

, rig]^^;l^„af de?g|||i^ selected by the error code. :, , , , , ai.v,s: vr| 

• Trap 8 (Double Fault) occurs if the processor, while trying to invoke an exception handler dueto'^ 
previous exception, finds that the code segment containing its entry point is not present. The diffi- 
culty of distinguishing between this and other double fault conditions implies that trap 8 is to be 
treated as an error condition, not a normal use of the present bit. 

Refer to Chapter 7 for additional information about these traps. 




SOFTWARE MECHANISMS ^ 

The operating system must provide additional mechanisms for a virtual memory system: one for moving 
a segment from RAM to secondary storage (the swap-out manager) and one for moving a segment 
from secondary storage to 'RAM-(the swap-in manager).' . - jt .-^iIj: 
' ■ .'^ •• \'v' »Ai ^mu^\ • ' ■■ r .[■. lur, OS MV', 'rt - ■ bm. 

The swapping managers are essentially I/O modules, but there are major differences be^sieeh Sfi(i^^j0§ 
managers and the functions of a standard I/O subsystem: 

• Swappers deal with executable segments, system segments, and data segments that are not normally 
considered I/O buffers. 

• I/O performance of svti^^^^^^SII^TsMxittt^ekMi fOr'ypecialiied'atfWce driveri 
■ allocation stategies. »«« " ■ » ' - ' ■■<>»*m 

: 'jiqir^aab i \ '.. i.. -r,,:,.)'-!- r/O'a aril 

Secondary Storage Mammnmr*'' "" '"^ "* 

. -i ■•• .1.*' J 

Virtual-memory mechanisms use a secondary storage medium, such as disk, to simulate a larger memory 
space than that provided in RAM. The operating system uses this secondary storage (here called the 
swap space) to store copi^ iOf these -stegments that are currently in the virtual space but may be 
eliminated from RAM. 

There are two general approaches Mloeating swap space for segments m dynamic systems: 

• The loader can invoke a swap-space allocation procedure as it loads the segments of a task. It can 

at the same time write an iivltkdriatage. of the segment into the swap space. This is particularly 
useful for a segment such as to iexecKtabie Segment that is occasionally swapped in but may never 
be swapped out (when its RAM ifiWPB is'^i^^iWKith^ ssgai^ 
do not change. 

The operating system may invoke the swap-space allocation procedure dynamically, either when 
al^OEiting R3\M;for the s,e^CTt^6r at the firs* tltii^ t^he qperat^^ Sys|teifliivaji^ ^'^^^t',^^ 

Some operating systems may implement both approaches. A system that allocates swap space only at 
kiad-time cannot swap out certain segments; namely, segments that a bootloader creates initially and 
se^menlfitfaat ttee operating«3^eiSMMi#8l^s(m(e9i%i. lit«(iaii^5$st9iai|iMi&i5 not a ptoMeth.i^efi 
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those segments that are bootloaded are just thi segments that shdidd tet be swapped out. CMmt^p^iaX- 
ing systems may allocate many segments dynamically; stacks, mailboxes, variable-length atraj^j etc. 
These systems may need both approaches. 

In designing a dynamic swap-space allocation scheme, you should consider at what time it is best to 
allocate swap space. The procedure that first allocates RAM space for a segment (a loader, for example) 
often creates a writable data segment descriptor. Later, when the procedure has initialized the segment 
(for example, by writing descriptors into a segment that i$ to be used as an LDT), it modifies the type 
code in the descriptor to reflect the intended use ot tha^iiffi^M^firtSfk -^fiiiait ft: would change the 
type to LDT). By delaying the allocation of swap space until first swap out, the operating system never 
allocates swap space for segments that it never swaps out (there is no need to allocate swap space for 
an LDT, for example, if the operating system does not support swapping of LDTs). 

Once the operating system allocates swap space for a segment, it must store the swap-space address in 
a location that is easily accessible when it is time to swap the segment out; Two possible mechanisms 
for storing the swap-space address are ' - '-^ ■ ! 

• In a boundary tag of the segment, if boundary tags are used. (Refer to Chapter 3 for an example 
of a space-management scheme that uses boundary tags.) - -• • ; 

• In a table parallel to the descriptor table. 

To determine whether to call the swap-space allocation procedure when it is time to swap a segment 
out, the operating system can test whether the swap-space address field contains a null value. 

When a segment is not present, the operating system can use the 24-bit base-address field in the segment 
descriptor to store the address of the swap space in which the segment is stored. As long as the present 
bit of a descriptor is reset, the processor does not use the base-address field. Storing the swaprSpace 
address in the descriptor also makes the swap-space address readily accessible to the "not-present" trap 
handler because tjipj, error code preseflted t,a the tra|i Ija^ijdl^^^ppteiiis a sele^^^ the descriptor for 
the not-present segment. 

- ■ ■ • liui. hvi, _ 

Level Zero Support Procedures ■ s'^^^^^ ^^^^ , i 

While the swapping procedures are I/O procedures that should run at privilege levels greater than 
zero, protection of the system demands that highly privileged procedures carry out softie detliQs of the 
swapping process. Only privilege-level (PL-0) procedures have the right to perform such activities as 

• Create read-data or write-data alias descriptors with which the swappers can access the segments 
they are operating on 

• Change the present bit in a descriptor ^ 

• Overwrite the base-address field of a descriptor 

• ""Prevent the swapper from operating on segments that must remain RAM-resident 

• Update all the alias descriptors for a segment pitii. its wew . status ; : ,. . , 

The following checklist identifies some of those segments that should remain pifManently ih RAM (in 
your application, there may be Others): 

• The GDT. (It is the key to ail addressing operatfDMfi) :ji3l5i: 1,. . ■ : r 

• LDTs that refer to present segments. (The protess^ e^ot access an LDT s^ment without fetch- 
ing its descriptor from the LDT.) 
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• T§Ss that point to present LDTs. (You cannot switch to a task and use its LDT without referring 
to-its-iFSS^. AK-s J I : ."'-iL.n - ■:. :- !. 1- 

• TSSs whose NT (nested task) flag is set. . . 

• Certain operating-system kernel segments that are frequently referenced (for example, the segment 
or segments containing the scheduler's queues). (System performance may degrade excessively.) 

• Segments belonging tJ( the swapping managers. 

• I/O buffers th^; are li*^ J)y an external device. 

• Executable seigments 'Ui8fe^«i«4tiB-4lie«ntry' point of an exception hancyer. (An exception^wo^^ 
' resti'lt- in double fauW.jh'f' '^f' ' ■ ■• . •^tHooll'; 

Note that, while the iAPX 286 does offer mechanisms that support swapping of TSSs and LDTs, doing 
so is likely to cause not-present faults in PL-0 procedures and to cause unacceptable delays in invoking 
interrupt tasks that are not present. For either of these reasons, the designers of an operating system 
may elect not to swap out TSSs and LDTs. 9t& .^-n-Aib'j. ■> . — i 

Swapping Managers < ' ' 

Swapping miEtnagers may need to distinguish between two classes of segments: 

• Segments of a task supimtMe$!li&'(the TSS, the task^al:®tme (T©Bi)^: and- possibly' the lei«el-zm 
stack segment) 

• Segments not part of a task superstructure 

Swapping of the task superstructure requires that swapping managers be aware that the kernel may 
treat the TSS as a "subsbgment" of the TDB, which may itself reside within the level-zero stack (as 
outlined in Chapter 4). The swapping managers shbuld tre£t th^ signii^Si]^ as a unit. 

Considering the complexities associated with swapping the segments of the task superstructure, it is 
perfectly reasonable for an operating system to simplify its virtual-memory subsystem by leaving those 
segments in RAM for the d«anttti88rf*e task. c^.uoejvM-. . iuc c i^voJ 

OUT-SWAPPER 

The out-swapper works best as a separate task; when the out-swapper must wait for the swapping- 
devicejyQ,^er to write f jj^pnieiit^jot^fffj^ks ?^^^ including the tj^.j^fc^ segment 

is being swapped out. . . .j 

The out-swapper's responsibility is to 

• Mark all the descriptors for the segment "not present." The out-swapper must ensure that the present 
bits in all descriptors for a segment always appear consistent. It must use a semaphore or region to 
preventotheraccesslpftealiases'WhffisM iS Aan^i^'pt«sent bi«: "I"-'' j W, lit l o 

• Copy the swap-space address into ail the descriptors for the segment (or possij?lyj> depen||jy9g. .op 
alias implementation,' into a "master descriptor" that is linked to other descriptcffs).' ' 

• Create a temporary data-segment descriptor to give the swapper the right to read the segment. The 

operating system must not move or delete this segment until the out-swapper is finished with it. 

• Write the segment to the swap-space allocated for it (but only if the segment is writable and its 
accessed bit is set). i TCLI adJ • j.- i : 
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• Return the RAM space used by the segment. 

• Delete the temporary data-segment descriptor. 

IN-SWAPPER . - : • jr! r .ziasJ isflio lo EJsa igoiq srll sa2)i;.T. . . r.ri. 

In theory, the fetch policy module, invokes the in-swapper. In practice, when the fetch policy is "on 
demand," the in-swapper is the "not-present" fault handler, which may also be called by the stack 

segment fault handler (for not present stack segments) and by the "invalid TSS" fault handler (for not 
present LDTs). The not-present fault handler can run as a procedure in the task that caused the fault. 

There is one case, however, that such a procedure cannot handle well. A dispatcher procedure running 
in task A causes a not-present fault when switching to task B whose TSS is not present. If the not- 
present handler procedure continues running in task A, then task A must wait until task B's TSS can 
be swapped in. Whether this is apmMein depends im-t&c.]!QleiQf!taskiA3^di« 4^ not- 
present handler procedure can avoid this situatioa bji'SU^iuli^^s^'B sn4 wndiAg a message to yet 
another task that is dedicated to swapping in TSSs. 

The steps that an in-swapper procedure takes are to i ; v 

• Get the swap-space address and segment size (limit) from the descriptor indicated by the error- codsi. 

• Allocate a writable data segment in RAM large enough to receive the segment. ■ 

• Copy the segment from swap ^piluc»>to the newly allocated R;^^-^p%§egi 1^3,! , 

• Update all regular descriptor' ft)r" the segment with the new ftaifc JiSdll i S , setting the present bit 
and resetting the accessed bit. (The base address comes from thfe tfeiiij(>bM>y writable data-segment 
descriptor.) 

i .i^ethe^tejitp^writ^^ '. 

An in-swapper task for not present TSSs gets a message from its input mailbox that identifies the 
descriptor for the TSS and identifies the task to which the TSS belongs. The in-swapper task performs 
the same steps as an in-swapper procedure, but it must also inform the scheduler when the task is 
ready to run. You can avoid the additional complexities of not-present TSSs by. not swapping ,TSS$ 
out. 

COORDINATION OF IN- AND OUT-SWAPPER 

A number of interactions between the iit-swap|)ef ^ifd'Out-swa^j^r presient pitfalls that the operatiz^ 
^^M'Jrnist avoid: ' iKsviO ,5(3ilo<i bniirrob '•rfi nsrit laiJad ^rino'l .'■ y'::i;t-i 
■ vj^:^ ■ , '■■ 

•' 'AWsk may attempt to use a segment that is being swapped out. If the in-swapper does not handle 
this possibihty, if may swap in old, erroneous data from the swap-space. ■ 

• Task A may request swapping in of a shared segment that is being swapped in for task B. If the. in- 
swapper blithely reads in the segment again for task A, it may overwrite changes made by task B. 

• A task may delete a segment that is being swapped out. If the swap-space release procedure does 
not allow for this case, the segment's swap space may be released and reallocated while thei out- 
swapper is writing to it. 

The in-swaj^r, out-swapper, and swap^^cie^release'prooedttfes <»n' coittitii interactions by 
maintaining a shared table of all segments that arein transition. They must use a semaphore or region 
to coordinate access to the shared table. The swap-space address can serve as the segment identifier in 

thetable. : . r- r;..,,:, i ^ir tu-rir. :;jv.v-;c' ^--y 



9-8 



121960001 



A virtual memory system gives each tasic the opportunity to affect other tasics in the system. Tasks 
compete with one another for real memory resources. One task may attempt to use memory in such a 
way as to unduly impede the progress of other tasks. The operating system must enforce JliMilMtfe!^ 
ensure that every task makes appropriate progress. 

Virtual mefflMy -iaanageiftiMit policies are not unique to the iAPX 286; the computer-science literature 
Contains md^iftMsUiMoni bf^pciUcies tliatipi<^y to'l^fimis classes of applications. There is, howeveri^ 
distinction between segmented architectures and pagc^ architectures. The iAPX 286 has a segiSteflted 
architecture. Literature that deals with paged architectures may not apply to the iAPX 286. Refer to 
the paper by Denning (see "External Literature" in the Preface) for a broad survey of the science of 
virtual-memory management. 

The remainder of this chapter is an introduction to memory-management policy. The policies you need 

Fetch ;*-(,-• /i? . •.:i.;';v>'n , ■ ; ' , iU. jdT 

Tliefetch policy determtees wJiicb s^mcintitotoiiqg From swap $i»(^Mto'J&yi('aa^d|iawMt9«ben 
to bring it in. 

The simplest fetch policy is to bring in a segment on demand, that is, at the time it is referenced. 
yndk^F this p(Edicy<;flke ogurating system brings in a segment from swap space onl3^;i^|i^f|^e processor 

All other fetch policies are in some way anticipatory. A simple example of an anticipatory fetch policy 
on the iAPX 286 is to always bring in the LDT of a task when bringing in its TSS. Some time-sharing 
systems implement an anticipatory policy that brings in all the segments of a task at once. This policy 
may be suitable for tasks that consist only of one code segment, one or two data segments, and stack 
segment (as, for example, simple BASIC programs submitted by students in a university environment). 
The swapping managers can use the segment register fields in the TSS (CS, DS, ES, SS) t,o identify 
fh^'te^S^lsWiKng'Set. ''■^ ' J"S'.3lq-l"n l.. ■■■::i:r^<f(:-ao l^ovihr,^ Wc -j-j v<i .; ;: ■ . 

Attempting to implement such a full-task swap policy for more complex tasls that use mmy segments 
may result in frequently fe^^ii^ si^ents that are nol^w^msvm^nmm^iim^ »tin*rsU5fe,Ti :iHOO0 

The additional complexity of implementing an anticipatory fetch policy is justifiable only if the antic- 
ipatory policy performs better than the demand policy. Given the efficiency of the iAPX 286 exception 
mechanism and given that in a multitasking environment there is usually some other task to service 
while one task waits for the in-swapper to fetch a segment, an anticipatory policy typically does not 
provide significantly greater throughput. An anticipatory policy may give better performance, however, 
when judged by performance standards other than throughput (for example, interrupt latency for specific 
tasks). 

PteOCilllSlft' ' >■ 'rt bn* ti'i. j-.-j'vi sr. /';)" ■J.-J; '-,.' - M.iT,]:'.-., 

Determining where in RAM to place an incoming segment is the subject of Chapter 3. In a virtual- 
memory system, however, the constant reallocation of real memory to segments of varying length places 
special demands on the operating system's memory management module. When choosing a space- 
management algorithm for a system that includes virtual memory, you may. wish lo-give ^tra ieonsid? 
eration to the trade-off between speed and memory fragmentation. '.\ 
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Replacement 

The operating system may need to replace one or iBOTe other s^ments that already reside in real 
memory to make space for a segment that is the object of a "s^ment-not-present" fault. The replace- 
ment policy determines which segments to eliminate and when to eliminate them. 



The choice of which segments to evict from RAM is crucial to the performance of the system. The 
goal is to evict only segments that will not soon be referenced. The difficulty is knowing which segments 
Ml not soon be T^feteBCed. Many different policies are discussed in the literature. They fall info liinie 
general classes: 

• Naive policies that determine y(hif^ s^iajeui^to evict witteJUt any. knowlibdge of segment access 
patterns i ■ i ,r. a.?mti • .V' s['ji,u.. 

• Historical policies that use information about prior aooess patterns to determme the probability 

that a segment will soon be referenced 

• Optimal policies that use analyses of actual program control flow to determine the probability that 
a segment will soon be referenced 



HISTORICAL POLICIES 

The iAPX 286 architecture supports gathering of historical information about actual segment access 
patterns via the accessed bit in executable and data segment descriptors^ An operating-system module 
that periodically tests and resets the accessed bits of descriptors can develop a "profile" of segment 
usage. The information gathered this way can be used both by the replacement policy module for run- 
time decision making and by the operating system designers for improving replacement policy. 

A "profiler" works best if it takes samples at regular intervals. To find all descriptors, it must step thru 
LDTs. A profiler does not need to examine all descriptors in the system each time it is invoked; it needs 
only to examine those of tasks that have run since the last time it was invoked. The same timer inter- 
rupt procedure used by the scheduler can invoke the profiler at appropriate times. 

A profiler may run either as a separate task or as a shared procedure in the current task. A profiler 
that runs as a procedure in the current task can easily locate the LDT with an SLDT instruction. The 
LSL (load segment limit) instruction helps the profiler find the size of an LDT. The LAR (load access 
rights) instruction enables the profiler to test the accessed bit. A profiler that runs as a separate task 
may require the support of a PL-0 procedure that locates LDTs and tests accessed bits in other tasks. 

A profller must give special consideration to aliases. If the accessed bit in any of the aliases of a 
segment is set, the segment has been accessed. Here again, a PL-0 segment may be needed to step 
through the kernel's alias lists. 



OPTIMAL POLICIES 

Many of the optimal policies discussed in the literature are of theoretical interest only. They are used 
as a standard against which to measure the performance of more practical policies. 

The segment-register fields of the TSS provide support fot a trivial, but possibly useful, optimal policy. 
The replacement policy can assume that, next tmrn any 0iea tmk mm, all the Kgments identifled by 
the CS, DS, SS, and TSS fields of the TSS will be refereiK^ The processor loads all these registers 
during a task switch and causes a fault at that time for each not-present segment. Since the task cannot 
run if any one of these segments is not present, the replacement policy may as well replace all of them 
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at once. It then becomes possible to allocate swap space for these segments in such a way as to ixMipteeS 
seek time. Such a policy works well with the full-task fetch policy outlined previously. 

THRASHING 

If not carefully controlled, the I/O traffic in support of virtual memory may degrade system perform- 
ance beyond acceptable limits. The worst case of performance degradation is called thrashing. This 
l!!^J?JP?8S^y'&SP.%/^^>JS^®Sf^^fi4 !to. si)mi}l?Jia|;,;^,,§3|^f»f4yr,i^^ and the 

behavictt of tne tasks in Mt s^ce is such that no task can run without causing a not-present fault 

You can avoid thrashing by measuring or estimating the minimum amount of RAM a task needs in 
which to operate without causing frequent not-present faults. If the task loader knows this figure, it 
can refuse to load a task when not enough RAM is available. You can measure a task's RAM require- 
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SYSJEM INITIALIZATION 



The initialization performed at power-on or RESET by the 80286 processor is not, by itself, adequate 
for running in protected mode. Software must perform additional initialization before it is possible to 
fully use protected mode. 



INITIAL STATE 

When you power up an 80286 system or perform a RESET, the state of the processor is as follows: 

• The MSW (machine status word) is zero; i.e., the 80286 starts jruBaiQg Hi the real-addr^ mode. 

• CS:IP be set to F000:FFF0, and the CS limit is OFFFFH. ' ■. m • 

• The four high-order address lines A23.20 automatically asserted for all subsequent references to 

CS until your initialization code changes CS. . 

• SS, DS, ES are set to zero, and the corresponding limit registers are set to OFFFFH. 

• The flag word is zero. This means that the 80286 starts running with the maskable interrupts disabled. 

The initial state of the address lines and CS:1P causes the processor to begin executing instructions at 
physical address OFFFFFOH. Presumably, this addresses a JMP instruction in an initialization proce- 
dure located in ROM or in RAM that has been loaded by another processor. The initialization proce- 
dure may occupy any portion of the last 65,536 bytes of the 16-megabyte address space. The JMP 
instruction at physical address OFFFFFOH transfers control to the actual banning of the initialization 
procedure. The first instructidn that modifies the CS r^itter causes tfae processor to cease asserting 
tii^^igliHordi^r fbt^ address lines; therefore;'t&eteEii@ftl&b^idii^i«^»«^ aVM^^^ any instruc- 
tions that modify the CS register, except for the final JMP ioitraction. ' 

The initial state of the DS, ES, and SS registers gives the' iiiitialization procedure access to the first 
65,536 bytes of the address space. The initialization procedure may change these registers, however, 
to gain access to any location in the first megabyte of the address space. (With regard to segmentation 
and addressing, the 80286 in real-address mode behaves just as an 8086.) Access to othei^ po^tkMs of 
meinory is possible only after switching into protected mode. 

SWITCHING TO PROTECTED MODE 

You use the LMSW (load machine status word) instruction to set the PE bit in the MSW, thereby 
switching the 80286 into protected, virtual-address mode. The current privilege level (CPL) starts at 
zero. The segment registers continue to point to the same physical memory areas as in real-address 

mode. -r:^:.: rWr^'lillj:. r. ^1 > ^ - . 

fmkediktdy after settmg the Pfe flsCg, tft^ iiiftis^SSlAilnasas^llSl'fltlsh' thfe processor's inStPtldtion 
qiieues by executing a JMP fnstruction. The 80286 fetches and decodes instructions and addresses 
before they are used; hbwevel, after a change into protected, virtual-address mode, the prefetched 
instruction information (which pertains to real-address mode) is no longer valid. A JMP forces the 
processor to discard the invalid information. An intrasegment JMP will cause the processor to drop the 
four high-order address lines; however, in protected mode this is not a problem. All addressing in 
protected mode uses the 24-bit base address froin the segment descriptor; so, once in protected mode, 
all of physical memory is accessible. 
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You can do most of the initialization needed for protected mode either before or after switching into 
protected mode. If done after, however, you must be careful to order the code so that it ioes not use 
protected mode features tliat require initialization that is not yet completed. 

.•■H« I':'"! >* ■ • ■ T»»-. j»iq oKiOo :.n> T.IH ifi no /ic-isv/^v-, *nn:'. -.n noiinz'Az- mIT 

Interrupt Vector 

The initial state of the 80286 leaves interrupts disabled; however, to ensure a predictable action in case 
an exception or non-maskable interrupt (NMI) occurs, it is a good idea to initializ^ES^IDT te^H/il 
Since it is unlikely that the NMI interrupt handler or any exception handler has been initialized, the 
most appropriaffe'valtfe to Md info tRe~fDT it|lstfef is zeros, thereby guaranteeing a shutdown shouW 
an interrupt happen. (The 80286 signals shutdown externally as an indication of a severe problem.) 
Later, when interrupt service routines are ready, you can change the IDT register to point to an actual 
IDT that c^iittins gate desei^lM §m ^epp:^^^0.fi3f^^iiff^/^ni;^^ i3^efjafi,pmb^.9.%p»\ ^e. . 

. :■'!■•■ .'r^-i. • . Ill lol bsnszjji ,'_/!uoij M-.-oJut -jij 

Stack 

Before you perform any stack operations, whether in real-address mode or in protected, virtual-address 
mode, you must load the SS register with a descriptor to a stack segment in RAM. If the SS register 
is loaded in real-address mod5,:itcpnti.nu^,fo_,point tg.tj^^S^cy^|^|| 

virtual-address^mode. a.:^,:,.,' ,/o.'v-,Lb'^ -^iiij' /^Idiirr'u, ■' >(R inMO rtJifabfi" ' ^.t;.; 

Global Descriptor Table 

Before you change any segment register in protected, virtual-address mode, the GDT register mu^t 
point to a valid GDT. .BDiU'ji.v.r,; ^.Wl ie.nn -rU iqsnr.s .Tj!,;ia3T 2',; .••.I -.-t.' jr inou 

Tdfie QiDT (asfl^ s$ijLiDl«lrsjbj9j9l|^,T@^dp Wi^M because the processor moiiSfisi^f^^nSfisd bHrtii 
descriptors. .f . 



Tp allow full ;^^in$gabyt& addressing in the initialization code, you may find it convenient to build a 
temporary GDT that contains only enough .descriptors to permit the initialization procedure to read 
the GDT segment from ROM or from a bootloadable module. After placing the real GDT into RAM, 
you can change the GDT register. 

3aoM 03103 TOR'-"- OT z>m-i ms 

Xbei iaitisliz^^ PMedugsitfim r)iA.awhile iii.pF^te^^Qd.wdf wi^.pfit: i^^lizing the task register^ 
however, before the first ta^ switch, two conditions musit prevail: , . 

• There must be a valid task state segment (TSS) for the new task. The register fields of the TSS 
should have appropriate values, the segment register fields must point to valid segments or be null, 
the stack pointers for privilege levels numerically less than or equal to the initial CPL must point 
to valid stack segments, the LDT pointer must point to the GDT entry for a valid LDT (or be null 
if the :t|i^4i«»iK>| use an: UBfl) mA, just m inswaiiQe, ,the .^aekilink itf .^e TSS should be null. ■ - 

• The task register must point to an area in which to save the current task state. After the first task 
switch, the information dumped in this area is not needed, and the area can be used for other 

purposes. altilc^.-j.^i. .•. ■ .r,.'in I .,<.. . M-) 10 ill) 
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Starting the first task is simply a matter of executing a long JMP via the descriptor of a TSS or via a 
task gate to that descriptor. This task can perform any remaining initialization work while enjoying the 
full protection and virtual-address features of the lAPX 286, the state assumed by the development 
todls. 



EXAMPLE OF INITIALIZATION 

The following figures present a detailed example of one way. to initialize a protected, virtual-address 
mode system. This example includes assembly lan|i^^iiiod^i^ It^^^rk in conjunction with Builder 
specifications. i^Xla iT^a-*? 1 

Figure 10-1 shows the primary initialization module ENTP (ENTer Protected mode). This module puts 
the 80286 into protected, virtual-address mode and invokes the first task constructed by BLD286. You 
use a module such as ENTP by binding it with other modules (presumably those constituting the 
operating system and the initial task) that you intend to place in EPROM. 

The module SpGS shown in figure 1 0-? supplies dummy segmept desprjptigjis for ENTP. The program 
INIT shown ik figure 10-3 serves as the tiAiaKtask. It merel}^^$^M$sli n^ssage when initialization isj 
complete. "-'^ -■ " 



J or ■ 
■* -A -H » • 



Initialization Module ENTP 

The steps that ENTP takes are to 



<- * * i. «f. .-v J 



1 1. 



• Switch into protected mode 
•■ Create a temporary GDT 

iCreate an IDT and GDT copy §i JR^^fro^cT^tiM in MitM^t^ ' 

• Point the CPU to the RAM tables 

• Copy all the TSSs and LDTs identified in the GDT from EPROM Jto RAM 

• Update the RAM GDT to point to the RAM copies 
JMP to the ifflftialization task in the GDT 

I - J -J. .. . 

The initializatibnS 'imrhediately following RESETjSTARTUP-are' PeSlundant. They simulate the 
hardware RESET initializations in case of a software reset or in case of a branch to 

RESET_STARTUP during debugging. ' ' ' 

1N1TIAL_GDT is a temporary GDT containing descriptors for the IDT and the main GDT in EPROM 
(the one constructed by BLD286). Since the symbols for these descriptors, GDT_DESC a.nd, 
1DT_DESC, are PUBLIC, the Builder can insert the actual base and limit values into the tabJe. . , 

The code in segment ENTP_CODE is self-relocatable. In aa EPROM-based system, you specafyi 
to the Builder the actual address of the segment ENTPjCOtM, making sure that th^'^By pdintj 
resides at physical address FFFFFOH. 

ENTP assumes a specific format for the GDT constructed by BLD286. The first two descriptors are, 
the data-segment aliases for the GDT and the IDT. The remaining descriptors are grouped according' 
to the template defined by T.^SK_ENTRY. Three adjacent descriptors identify the key segments of 
each task. ENTP adapts at run time to the actual number of such groups in the GDT. The task that 
ENTP initiates is.identified by-a-ilxed^aositioBJn. tiie.Xj.DT . 



121960-001 



1*PX^« NACIta ASSEMBLER 



Entar Protected Hod* 960-516 



data 



»yst»«-IO iAPX286 KACiJO ASSEMBLER VX.y AS'SeWtf BliWt* 
OBJtCT HUDULE PLACED IN :F1:ENTP.03J 
ASSEMBLER INVOKED 3Y: ASM286.86 :°l:ENTP.AB6 



LOC .b^ 



LINE 



SOURCE 



o 
I 

4^ 



1 

2 
3 
4 

5 
6 
T 
8 
9 
10 
11 
12 
13 
U 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 



♦1 tTITLEC 'Entar Protactad Moda 960-516') 



NAME 

PUBLIC 



ENTP 

lOT.DESCGDT.OESC, START 



•EJECT 





28: 










- , 29. 


; Daflna 


layout 


of 




- . 30 
- 31 


OESC ? ■-■ 


sf*ut 




0000 


L 32 


LIMIT 


D« 





0002 


r 33 


BASE.LOW 


DU 





0004 


-■ ^ 34 


BASE.HIGH 


OB 





0005 


35 


ACCESS 


DB 





0006 


36 


RES 


DM 







37 


DESC 


ENDS 





Sai^ch tha 80286 from raal addrass noda Inta protactad iRod^a. 

Tha Initial EPR3M GOT, IDT, TS5, and LOT (if any> eonstruetad by BLD286 
ara copiad from EPROH into RA'^. Th» RAM areas are definsci by data 
segfiiants allocatad as fixad »ntri3s i'^ thj GOT. The CPU regist»r« for 
tha GOT, IDT, TSS, and LET ar» set to point at tha RAM based 
sagmantt, Tfia ba*a fields in tha RAM GOT ara also updated to 
point at the RAM based segments* 

Interrupts are disabled during this moda switching code. 
The EPROM basjd GOT, ICT, TSS, and LOT are checked to assure 
they are valid before copying tham to RAM. If any of tha RAM-basad 
alias sasments are smaller than tha EPROM segments they ara to hold, 
halt or shuJ^doan occurs. In general any exception or NMI causes 
shutdoain to-soceur until tha first task is invoked. 

Tf the RAM segment is larger than the EPROM segment, the RAM sagwant 
is expanded aith zeroes. If tha initial TSS specifies an LOT, 
the LOT is also copied into LOT_ALIAS aith zero fill if naadad. 
The EPROM or RAM based GOT, TOT, TSS, and LOT segments may be locftad 
anyuhare in physical memory. 

-1 



(A 
-< 
(0 

m 
Z 

z 

> 

N 
> 



a dascrinjtor. 



38 
39 
40 



Offset of last byte in segment 
Lorn 16 bits of 14-bit address 
High 8 bits of 24-bit address 
Access rights byte 
Reserved mord 



Define the fixed GOT selector values for the descriptors that 
define the EPROM based tables. 



;^ . -1 . Figure lO-l- Inltializatton Mhidute BNTP-- 'e ^ ^ - . :j - ui £ v 



■ iAPmT M»C'SS~ASS'E«?rEi( 



LOC OBJ 



Ent»r Prdtect«d Hod* 960-516 



LINE 



SOURCE 



dat* 



P»GE 



0003 
0010 
0018 
0020 
0028 



0001 



0082 
0092 

0081 
O060 
0001 
0004 
002C 
002/1 
0007 



•Jti 
FEIO ., 
OlEO 

OlEO E969FE 



0000 



0000 

0000 0000 



41 
42 
43 
44 
45 
46 
47 
48 
49 

sa 

9t 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 

64 +1 

65 
66 

68' 
69 
TO 
71 

73 
74 
75 
76 
77 
78 
79 
30 
31 
82 
33 
34 
35 



GOT.ALIAS 


EQU 


1*SIZE DESC 


TOT Al T A*^ 


EQU 


2*SIZE 3ESC 


START_TSS_ALIAS 


EQU 


3*SIZE BSSC 


START_TASH 


Eau 


4*SIZE OESC 


STAR^T_LDT_ALIAS 


EQU 


5*SIZ^ SC: 


; 0»fln» 


KBcMni status MtrtS t 


RE 


Eau 


1 


; Dcfin* 


particular values of 


DT. ACCESS 


Eau 


B2H 


OS.ACCESS 


Eau 


92H 


TSS.ACCESS 


Eau 


81H 


DPL 


Eau 


60H 


ACCESSED 


Eau 


1 


TI 


EQU 


4 


TSS.SIZE 


EQU 


44 


LOT.OFFSET 


EQU 


42 


TIRPL_M»SK 


EOU 


I^SIZE DESe-1 


»EJECT 






; Pass control 


from the poioer 



GDTC13 is data segment space for GOT 
G9T(2} ts data sesment seaee for IDT 
SDTC33 is data segment space for TSS 
G0TC4) is TSS for starting task 
SDTC5)- is data; .segmtnt space for LOT 



Protection enable 



Access byte value for an LOT 
Access byte value for data segnent: 

expand up> level Ot oriteable 
Access byte value fo^r an idle TSS 
Pri'vIXage' l"»*rl Hit^ of access rights 
Define accessed bit 
Position of TI bit , . 

Size of a TSS ... ' 

Position of LOT in TSS 
TI and RPL field Mask 



up address to the mode sMltcti code. 



(A 
-< 
(A 
H 

m 



> 



The sagment containing this cods must be at physical address PFFEIOH 



to place 



tha 



J»P Instruction at physical acldrsss =FFFFOH. 



EMTP_C03€ 
CS'J^aFFSET 



address is chosen according to the size of this segment. 
SSGHfEMT ER 



EQU OFEIOH ; 

ORG OFF'OH-CS.CFFSET! 
JMP RESET.STARTUP i 



Lou) 16 bits of starting address 
Start at address =FFFFOH 
Do not change CSI 



Define the template for a tamporary GOT used to locate the initial 
GOT and stack. This data is copied to location 0. 
This space is also used for a temporary stack and finally serves 
as the TSS uritten into »hen entering the initial TSS. 



INITIAL.GDT 
NULL.DESC 



ORG 



LABEL 
DESC 



WORD 
<> 



Place remaining code belout poaer.up 
address 

Filler and null lOT descriptor 



Figure 10-1. Initialteatton Module ENTP (eont'd.) 



LOC OBJ LlVf SabVcE 





0000 


'1 T 

1' 


1 


0004 


00 






0005 


00 






0006 


0000 






0008 


0000 


36 


GOT.DESC BESC <> : Descriptor for EPR0>4 GOT 


OOflA 


0#00 






OOOC 


00 






0000 


00 




■ 


OOOE 


0000 






0010 


0000 


87 


IDT_OSSC DESC <> • Descriptor for EPROM IDT 


0012 


oooo 


il 




0014 


00 


0015 


00 






001« 


0000 






ooia 


0000 


88 


T = MP_0E$C DESC <> ;v. . c j; , .. ; Tenporary dascriptor ^ ^ , 


001* 


0000 


»'^- 




OOlC 


00 


OOID 


00 






OOIE 


0000 


85 

92 
93 


. -,- - , • -. ■ . . . ■ „ • i 

.5 

': Dofin* a jd.iscriptj>r iihich points tha at location 0. 
V Vhis dascriptor is also loadod into SS to d»fine tha initial 
; protected moda stack segment. 

* I. ■ T 


0020 


3f00 


94 


TEMP.STACK DESC <=ND_GDT-INITIAL_G0T-1,0,0,BS_«CCESS,0> 


0022 


0000 






0024, 


00 






00^*loOT 




1 jh , ■ 






95 ♦! 


JEJECT 






96 








97 
«B 


; Define the TSS descriptor used to alloa the task saitch to th« 
S first task to overarlte this region of namepy. Tha TSS o»«rl»yi 






(99 


i tha initial iGOT' and vtack at locstl«h< iO«' < 








i: 


0028 


3F00 


IM 


SAVE.TSS I,j (BfiSC <ENO_GOT-INITI*L_GDT-1,0,0,TSS_*CCESS,0> 


002* 


0000 


* f 


J 'in ' .. - . ^ , : ; , . J - . . , : f 


00£C 00 


«f 




002^ »l 




. - ■ . - . , . Oi 












102 


5 






103 


; Define the initial stack spaca and filler for the end of the TSS. 




•"c 1 


- jrtni 




0030 


C8 


105 


Oit 8 OUP CO) 



Wiai^l®-4?HwmaH Ka t te n Me < >iite-eHfy-(Gont*^ 



rurnu-nKCfsummLti inTir>fo«e"t«ri(5arr^siP-'sT6~ 



LOC OBJ 



0040 ^ 
00«0 

00*0 0000 
00*2 2000 



0000 
0002 
0004 



0044 2000 

0946 iMo,: 
0041 itot 

004* 0000 



004C 
004C F* 
0040 FC 
004E 33FF 
OOSO 8E0F 
0052 SECT 
00S4 SEDT 
0056 BC40Q0 



00S9 

0059 Eseodo 
oosc 

OOSC 50 
OOSO 83E05C 



SOURCE 

c if r 

tt3A 

EM0_6Sf r^rr 



LABEL 



LABEL 



:.itu»r ou.i 

MoiiJ9 

■ >^ 

OMORfii'i • .T' - ■■I 
OtST«(lT_TASK 



Pointer ts Inltiil tatk 



D«fin* tMplat* for th* task dofinitien list. 



T»SK_ENTRY 

TSS.SSL 

TSS_ALI«S 

LOT.ALIAS 

T»SIC_ENTRT 

TASK.LIST 



RESET startup: 
CLI 
CL& 
XOR 
NOV 
NOV 
NOV 

m 



STRUC 
DW 
OU 
OU 

ENDS 



I EJECT 



task_entry 

DM 



DI.OI 
OS, 01 
ES.OI 

ss.oi 

SPtEND.GOT" 



: 0«fin« layout of t*ik daaeription 

; Solictor for TSS 

t Data sogmont •ll«t fop'TSS 

S Data sognant altai for LOT if any 



<START_TASK,START_TSS_ALIAS,START_LOT_ALIAS> 



; No intarrupta alloaadi 
S Usa autoincranant noda 

t Point ES:OI at physical addrass dOOOOiH 



; Sat stack at and of ratar^fd araa 

INITIAL.GOT 



; 
: 

START 



from the real CS base of *=FOOOCH to the 
flSH286. Any data reference made 
term C3P1 to compansata for tha difference 
batuaan tha offset generated by ASM286 and the offset required from 
the base of FFOOOOH. 



pom an adjustment factor 
segment base address assumed 
Into CS must add an indexing 



STARTl! 



*"a*2 

r ;v 

CALL 
C 00-. 
POP 
SUS 

■tlOT 



STARTl 



BP 



BP, OFFSET START! 
mt.OESGCBPl 



The value of IP at run time is not 

the same as used by ASM236I 
Gat true offset of STARTl 



Subtract 5S*'235 offset of STARTl 

leaving adjustment factor in BP 
Set up null IDT to force shutdoan 
on any protection error or interrupt 



Hgttra tnitiaHzation-MotKito EMTP (Cont'd;) 



LOC OBJ 



0065 gO7&D0 
0068 B92000 
006B F3 
006C 2E«5 



006E OFOIEO 
OOTl 000100 
007* OFOIFO 
0077 EBOO . 



0079 2E0F01S620 
0D7E B82000 
0081 8ED0 

0083 33C0 
0085 OFOOOO 

0083 BS^ijOO 

%%%% mp' 



OOSE 2ESB460S 
0092 302FOS 

0095 723C 

0097 BB0800 
009« BEOSOO 
0090 ESD600 
00*0 BEIOOO 
aot3 BBIOOO 
00*6 E8CO00 

00*C SEDS 



1*7 
148 
1*9 
ISO 
151 
1S2 

153 
»S* 
»S5 
156 
157 



data 



'-rsst S 



170 
171 

172 *i 



SOUXCE 



REF 



Jiii Si>"St«J*l itWit : ""1 c-'-":! »''.'.a9 Oii?»r oi ;ifijii 

Cony th« EFII0N'-b»««4 t»iWor»r» »DT into R*M. 

c*rr ?i»ini - ■ 

IE* SI, IMITI*L_SDtt9F3 J wjafwtprtnt*!* qt»AG07 i -. . 

»3«C CX,CfN'0_6DT-tNITI«L_GBT)y2 ..'f Srt^liiiirfathi. 'j; i--- - ■ 

(iOVS ES:M0I!0 PTR C0I],CS:CSI3 ! Put into r«s«rv»d RAH 

M ft r- - * " 

^Saltch to pnataetad iiaala Mind iKat MP ;a stacVi ZDT, and LOT« .i . : . iSLMtca 



$EJ^CT ' 



snsw 

OR 

LMSW 
JMP 



LGDT 

«av 

HOV 
X3R 
LLDT 

MOV 
,LTR 



*X ' 1 v *iit-*b i t, tc 4 
AX.PE 
AX 



.{ iCat current MSW . t „ , , 

; Sat PE bit 

Enter protectad mods! 
Claar quaua of ipstructions decodad 

ahila in Raal Address tfode 
CPL is noa Ot CS still points at 
FFFEIO in physical mamory 



Put initial 60t into RAM area 
Setup SS inith valid protected mode 
selector to the RAM GDI and stack 
Sat the current LOT to null 
Any references to it causes 
• 'an'axcaption causing shutdown 
AXiSAVE_TSS-INI7I*L GOT ; Sat initial 7SS Into tha loa RAM 



TEMP_ST*CKCSP3 
AX.TEMP.STAGK-INITJAL^GOT 
SS.AX 
AX, AX 
AX 



(0 

-< 

(0 
H 



N 
> 



Copy the EPROH based GOT into the RAM data segment alias. 
First tha descriptor for the RAM data segment must he copied into 
tha temporary GOT. 



iOfliQ- 



NOV 

J3 

M3V 
MQV 
CALL 
MOV 

Mav 

CALL 

NOV 

MOV 



AX, GDT_DESCCBP3. LIMIT 
{*lkt»$«|t!$ oO E$^l ( «av 

eAD_GOT 

BX,GDT_DESC-lNITIAL_GaT 

SI,GOT_ALIAS 

CQPY_EPROM_OT 

SI, IDT.ALIAS 

BX.IDT DESC-INITIAL GOT 

COPY_cPROM_OT 

A X , 5DT_DESC-INITI*l_6rf 

OS, AX 



; Get size of GOT 

; Be sure the last entry expected by 

; this code is inside the GOT 

; Jump if GBtf i^am't big enough 

: Form selector to EPROM GOT 
; Get selector of GOT alias 
: Copy into EPROM 
; Gat salaeter of IDT alias 
: Intfienfa ePROM ICT 

I t**. mm ft(ltff*«.*i»g into Er^OH SOT 









m 


00*E 


bboboo 


OOBl 


OFdiit 


»084 


8bSE44 


OOBT 




0087 


E8iaoo 


00B« 


83C306 


OOBD 


2E8B0T 


OOCO 


OBCO 


00C2 


T5F3 


00C4 


BB0800 


OOCT 


BEOB 


0OC9 


B81000 , 


OOCC 


OFOllP ^ ^ 


OOCF 




0003 




0003 








0004 












01)05 


BEOlisI 


0008 


8EDE 


00O« 


2E8BT702 


OOOE 


8EC6 


OOEO 


0F03C6 


aOE3 


2E8B3T 


00E6 


0F0206 


O0E9 


7SE9 



III 



vrsveerts-Kssm a-sn 

»H0 . , ■ I'.C ,. 



PAGE 



1 93 
19« 
195 

IW 

Wi 

196 
199 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
214 
215 
21« 
217 

iis 

220 
221 
??2 
III 
?2* 
225 
226 

m 
m 

229 
230 
231 

233 

235 
236 



SOURCE 



] Get GOT alias dali'iilS^t st>l»«t«r 

S Set GOT to "(AM §pT 

; SS and TR remain'ln low R*M 



t Copy all task's TSS and LOT segments into RAH 

, s.-,.. 

t%ti eX,TASK_LISTCBPl 
CDPY_TASK_L30P: 

CALL CQPY.TASKS 

ADD BX.size TASH.ENTRY 

NOV AXiCStCBXJ.TSS.SiL- 

OR AX, AX 

JNZ CaPY_TASK_L3DP 



Define list of taskt.,|a up 



; Copy them into RAM 
• Go to next entry 
i'$«i"if 4h»^« li iitiethar antry 



With TSS« GOT, and LOT sat, start up the initial taski 

; Point OS at GOT 



BAO.GOT: 



START 
SEJECT 



HLT 
ENDP 



BX.GDT.ALIAS 
DS,9X 

BX.IOT^ALIAS ; 

||5||:*dt«^^(itBff 



Get lOT alias data segment selector 
Set IDT for errors and interrupts 
Start the first taskI 
The loa RAH area is overaritten aith 

the current CPU context 

Halt here if GOT isn't big enough 



■ifu set* tfll 



(A 
-< 
(0 
H 



Z 
> 



O 
2 



; Copy the TSS and LOT for thfxtas(i u^ettii'la^lMf (iS^SXavJuiiu i 

; If the task has an LOT it will be copied itewn, too. 

; BX and BP are transparent. 

|AO_TSSI 



caPT_T»S!iJb 
r?r 
nav 
Nsy 
(toy 
wov 

b»i 

MOV 
LAR 

JNZ 



PROC 



,1 • 



SI.60T_ALt«S 
DS.SI 

SI, CS:CBXJ.T$S_ ALIAS 

ES.SI 

AX, SI 

SI,CS:C5X3.TSS_SEL 

OX, SI 

BAD.TSS 



: Halt here if TSS is invalid.! 

; Get selector for TSS alias 

: Point ES at alias data aagmtnt 

; Get length of TSS .-aliai: - yz-.t 

; Gat TSS sal«etar 

; Get alias memm»* rlghtt 

f 40sm if invalid rafaranea 



Ligi-kCi iO t | Lti< i -iliirVf(, 







' ' ' 


LOC OBJ 




LINE 


OOEB 8A06 




J »T 
£31 






£39 


WUrU OVrCO* 






AAF? TKnP 










241 






242 


A A Fft fl IBQ^n 




2 4 3 


AACB T9nT 
UQ r B f £|J f 




2 44 


yd Of 




245 




246 






247 






248 


AAcn r&^AACo) 




249 


A1 At tt EflB 




250 


AiJIV CAABAA 




251 






2 52 






2 5 3 






254 






255 


oin^ BQnanA 
U 1 Uo oavovO 




25(5 


W1U7 ocUtf 




2 57 


ui UD V ecu 




2 58 


n 1 An 9 FAR 




259 


A11A 9FflltTVA> 




Zpv 


0114 A 5 ^ 




2 Dl 


0115 A 5 




£ D£ 


0116 AD 




2 63 


(1117 flAF7 




264 


0119 *B 




265 


011« «5 




266 






267 ♦! 






268 






269 






270 






271 


OllB 2E8E5F02 




272 


OllF 8B3&2/t00 




2 73 


0123 BlE6FgFF 




274 


0127 T441 




2T5 






2T6 


0129 S« 




2 77 


012A 0F02D6 




278 


0120 753C ' 




279 






m 


ai2F 8A06 




231 


0131 S0E69F 




282 









Mod* 960-516 



dstt 



PAGE 



S3U1CG 



' 1 li 


<: 


* 












HOV 


DLf DH 




Save TSS doscriptor accoss byt* 


AND 


DH.NOT DPL 




Ignore priviltg* 'ui 


CMP 


DH,TSS_ ACCESS 


• 


S*c if TSS 


4(iZ 


t»B_T$S 


; 


Jump If not 








C « i 


LSL 


CX.SI 


s 


Gtt l»n9th of ePR3M bastd TSS 


CUP 


cx,tss_si:e-i 


s 


Vorify it is of proper size 


JB 


BAD.TSS 


> 


iluiiip if it is not big enough 


S*tup for moving tho EPROM 


biisod 


TSS to RAM. 


points 


at GOT. 






MOV 


CSIl. ACCESS. DS^ACCESS : 


Make TSS into data segment 


MOV 


OS. SI 


i 


Point OS at EPROM T&S 


CALL 


C0PT_MI7M_FILL 




Copy OS segment to ES aith zero 








CX has copy count. AX-CX fill 



Set the GOT TSS limit and base address to the RAM values. 



■ MOV 
MOV 
MOV 
MOV 
MOV 
MOVSW 
M3VSW 
LODSW 
MOV 
STOSW 
M9VSU 



AX.GOT.ALIAS 

OS. AX 
ES.AX 

DI,CS:C3X].TSS_SEL 
ST. CStCBX^flSS. ALIAS 



AH.DL 



SejECT 



Restore GOT addressing, 



; Get TSS selector 

; Gat RW »»l«ct»r ■.,;s, 

i Copy Umil 

; Copy Ion 16 bits of address 

; Get high 3 bits of address 

; Mark as TSS descriptor 

> Fill'ln high' kridrass and access bytes 

S Copy reserved aiord 



See if a valid LOT is specified for the startup task. 
If so then copy the EPROM version into the RAM alias. 



MOV 
MOV 
AND 

it 

PUSH 

LAR 

JNZ 



CS.CS:CaX3.TSS_ALIAS : Address TSS to get ^0T„ „^ 
SI.DSIHORD PTR LDT_aFFSET 

; Ignore TI and RPL 

: Skip this if no LOT used 



SI, NOT TIRPL_MASK 
NO.LDT 



MOV 
AND 



SI 

OX. SI 

BAD.LOT " 
DL.OH 

CH.NOT OPL 



; S»ve LOT selector 

; Test descriptor -.Tet 

t Juip if invalid selector 

; S*v» LOT doertptor access byte 

i Ignore privirleg* 



■ Fi a ii re 



r E N T P (C oi U'd.) - 



i«PX2t6 N«CRO ASSENBLEIt 



LOC OtJ 

013« aOFESZ 
0137 7532 

013t 26C6440S«2 

Q13E 8E0E 
01^0 aF03C6 
01«3 E826aO 
01*6 8BCS 



Entar Prot«ct*d Mad* 96D-516 
LINjS SOURCE 



0148 2E8B7704 
014C 8EC6 ^ 
014E 0F03C6 

01 $4 tklMP 



0157 2E8B7704 
OlSB 5F 
OISC 880800 
015F SED8 
0161 8EC0 
01«3 «S 

0164 15 

0165 AO 

0166 SAE2 

0168 «B 

0169 «S 
016* 
ai6A C3 
01 BB 

01 6B P4 



016C 



016C 50 
015C 2*07 



1 



283 
284 
2«» 
286 
287 
288 
239 
290 
291 
292 
293 
294 

^1 
297 
298 
299 
300 

3ii 

302 

303 

304 

305 

366 

307 

308 

309 

310. 

311 

3S2 

313 

314 

3J$ 

316 

317 

318 

319 +1 

320 

321 

nti 

3«»i 

324 

325 

326 

327 



CMP 
JNE 

MOV 

MOV 

LSL 

CALL 

MOV 



DM,DT_ACCESS : 
eAD_LD7 : 

ESrCSn.ACCES SvtS.ACC ESS: 
DS.si : 
AX, SI ; 

7ES7_DT_LIMI7 



CX.AX 



Be sure it is an LOt 4miiBt'iil0tmP 
Jump if invalid 

Mark LOT as data sagntnt 

Point OS at EPROM LOT 
Gat LOT limit 
Verify it is val^d 



i Sav* for latar 



Ef|;#il)a tha LOT alia* segment and. if 9m#i«>|gf|ra1^(i 

Get LDT.allai talactor 
Point ES at alias' tagisfift 



MOV 
MQV 



SItC$:CBX3.LDT_ALIAS 



" 1 >■■ I i 



AX. SI 

TS$T_OT_Lt«T 



; Gatlangth of flias itgmant 



LSL 
CJltt 

Sjfiiy[tha LDT limit and base addrass to the RAM copy of the LOT. 



NP_LDT: 
BfPiLOT! 



Mav 
pap 

MOV 

MOV 

MOV 

MOVSW 

MDVSH 

LOOSW 

MOV 

STDSW 

MOVSW 

RET 

Hit 

I 



SI,CS;CBX3.LDT_ALIAS 

DI 

AX,GDT_ALIAS 



CaPV TASKS 
»EJECT 



OS, AX 
ES,AX 



AH.OL 



ENDP 



■ »OCf 



Restore LDT alias selector 
Restore LDT selector 
Restore GST addressing 



, H e CI- rt^^OL 



I • 



Move the IJAM LDT limit 
Move th9 Ion 16 bits BCrois 
Get the high 3 bits 
Mark as LDT daacriptor 
Set high addraa* and accast rights 
Copy res*ry^^jfff5^. ... irar/i 

a b ni. Y .. A t* . i 4 ') ; u » » T r 9 g 

All dona 

Halt hara if LDT i> Invalid 



(A 
-< 
(A 
H 

m 
S 



> 
I- 

N 
> 



I 



Test the descriptor table size in AX to verify that *t il •« 
• van number of d«S:Criptsrs In langtl«»{^ . , 



TEST_DT_LIMIT 

PUSH 
AND 



PROC 



AX 

AL.T 



Save langth 

Look at loa order bits 



i«PX286 NMRO «$SeitBI.ER 



3IPt 


(0 


LOC 


OBJ 


Ol&F 


3C07 


0171 


58 


0172 


Tsei 


017* 


C3 


0175 




0175 


F4 







0176 

0176 
01T8 
017A 
017F 
0185 
0188 
01«« 
018D 
0190 
0192 
0195 
0196 
0197 



8CD0 
8EC0 

26C6470S92 

26CT47060000 

0FO3C3 

SBC8 

ESOMF 

BFOSOO 

8EDF 

BF18Q0 

57 

«0 

^S02FF 

.a* 



019A IB 

019B *S 

019C *5 

0190 *5 

,0i9E.97,;,a 

,0t9F,8E{)B'.< 

.• : . t. z-i'L 



Enttr >ret«c't«d Moda 960-516 

JSi ■ .1 <• ■ . 



'ill 



PBGE 



3S« 

333 
334 
335 
336 
337 
338 

?J9 
340 

344 
345 
346 
3*7 

:j*8 

349 
350 
3S1 

352 

$$6 

■Ml 

<;3M 

3»o 

•1*1 
si«2 

.1*3 

.l«5 
366 

367 
368 
369 
370 

371 
372 

f 3T»3i 



SOURCE 



CMP 

■ .P.QP 

, r;t 

B«'lj_DT_LIMIT: 
HLT 



TEST.OT.LtHIT ENDP 



AL,7 

AX , . 



9 t*** I«»«*l> 

; Must l^e 2)11 on»s 
; Restor* langth 
ru i« A#wl > > . -'d : ¥ ; 

: All OK 
: oi«! 



Copy tha EPROM DT at s*l*ctar BX in the temporary GDT to the alias 
data segment at selector SI* Any i^nproper descriotors or limits 
causs shutdoani i.7Ap( 



COPY.EPRON.OT PRCC 



H3V 

M3V 

M3V 

MOV 

LSL 

MOV 

CALL 

HOV 

MOV 

M3V 

PUSH 

LODSW 

CALL 

STOSM 
M3VSW 
MOVSM 

Mavsw 

zm 



CaPY_£PROM_BT 
•I »EJECT 



Point ES:Ot at tenporary descriptor 



AX.SS 
ESiAX 

ES:CBX].ACCESSiOS_ACCESS: Mark dascriptor at 
cS:CBX].R|S«0 
AX.SX 
ex. AX 

TE5T_0T_LIHIT 
DI,S0T^DESC-1NITIAL_G0T 
DS.OI 

DI.TEMP_DESCfINITI*l_GDT 
DI 



data sagiswnt 

Claar r«s*rv.ad fiord , 

Sava for latar 
Verify It is a proper limit 
Address EPRQM GOT In OS 



TEST_DT_LIMIT 



e»o~rai 

Oi»W"»CCe?2 



: i f 2 ; 



Get selector for temporary descriptor 
Save offset for later use as selector 
G|t,'a],ias segment size 
Verify it is an even multiple of 

descriptors in length 
Put length into temporary 
Copy remaining entries into temporary 



: ES noa points at the GDT alias area 
; DS noa points at EPROM DT as data 
; , Cogy segment to alias with zero fill 
■•w^k is copy counte.liTPV till count 
: Fail into C3PY_WITH_FILL 

I sa *flt.B l( tz ' isicvia^ek 



(A 
■< 
0) 
H 

m 
S 



-I 
> 



N 
> 



Copy the segment at DS to the sagnan-t at ES f«r length CX. 
Fill the end altti AX-CX zeroei. Use mord oparattont for speed but 
, jilVgil q^d. b)jts operations. .^ ^ 



»-to=ir1 



CO 



1APX2B6 MACRO ASSEMBLER Ent«r Prot«ct»<l Madt 960-516 



dat* 



PAGE 10 



LOC OBJ 



LINE 



SOURCE 



t.t! 







37* 


; 






OlAl 




37S 
376 


COPf_HITH_FILL 


PROC 




OlAl 


33F6 


377 


XOR 


SI. SI 


; start at beginning of s«gni«nts 


01A3 


33FF 


3T« 


XOR 


01. 01 




OlAS 


2BC1 


37* 


j: SUB 


AX.CX 


; Form fill count 


OlAT 


83C101 


3S0 


ADD 


CX.l 


« Convert limit to count 


OlAA 


D1D9 


381 


RCR 


CX.l 


; Alloa full 64K novo 


OlAC 


F3 


382' 


REP HOVSW 




: Copy DT Into alias araa 


01 AD 


AS 










OlAE 


91 


383 


XCHG 


AX.CX 


; Get fill count and zaro AX 


OlAF 


730T 


3ft4i' 
38S 


JNC 


B«E«_COPY 


; Junp if avan byta caunt on cdpy 


OlBl 


A4 


386 


MOVSB 




fl Copy odd byta 


aajtx, BBC 9 


387 


OR 


C»*,CX i . : ., . 




OlS* 


7409 


388 

3»9i 


lei' JZ 


E»rr-jCOlP» 1 


! Exit if na fill 


01B6 


AA 


3W 


rai't- STosB 




; ; Eyen out the segment offset 


OIBT 


♦ 9 


391 


DEC 


tx 


* Adjust remaining fill count 


01B8 




392 


even.copy: 






01B8 


01E9 


3931 


SHR 


C», 1 


; Fomi -aord count on fill 


OIBA 


F3 


39« 


REP STOSW 




; Clear unused words at end 


01S8 


• B 










OIBC 


7301 


395 


JNC 


ExiT_copr 


; Exit if no odd byte remains 




J .\ . ^ 


396 








01 BE 


AA 


397 


; «ms8 




: Oi. »S ^M»n,^4«»t «<lid„*y?*iar I - ^ ■•a- c.i 


OIBF 




398 


EXIT_COPY! 






01 BF 


03 


39« 


mr. 


^ r-.i.-.i "C:t 








401 


GOPr.MlTM.FILL 


ENO.P ■ . t'ii- :• -1 








402 








tw 






OKTAUGOeE 


ENDS 




t 


Ml* LINE «403t SEGHENT CONTAINS PRIVILEGED INSTRUCTIONS 








404 




END 





• isj-„, ■■ MVtfB vitztsrn '.X-}. is 



Mix CJc; 
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1APX286 M«CRO ASSEMBLE!! DSFINi SEGMENTS Nr53E0 ^OS IMIT C3Cc 

systei»-ID iAPX286 MAC5D ASSEMBLER VX.y ASSEMBLY Of= MCOULE SEGMENT_3£F 
3BJECT MODULE PLACED IN IFIISEGS.OSJ ., . , 
ASSEMBLER INVOKED 3Y: : ^1 : A S M 2 8 6 . 86 ;=1;SEGS.«86 



dat* 



PAG: 



I 



SI i 



LQC OBJ 


LlNf 

- ' 










. . I 1 i 








t-i-'^ •>•: 




0000 ??7t 


, 1« 


n r 


8 


OOOO (8 


9 
10 


7?7? 






; 5 I 




Ida 






0000 C8 








} 


1 -J 




15 




16 




17 


wo tcs 


3»I8 


: ¥ •; [9r71!i? 


381 


) U.J 


}80 










')Tvr :<3isc 




0000 (8 




01 »T 7777 






3 i- 




23 




24 




25 



S3URCE 



JTITLEC 


"DEFINE 


SEGMENTS 


NEEDED 


FCR 


INIT CODE') 






SEGMENT. 


.DcF 














: Qefine stack so mada .isjui'teh cod* em 


INIT_ST«iKB2S 


SEGMENT 


RM 








DW 


? 




', run in protected node 


INIT_STAC«^ 


iCMOS 








LDT.SEG 


■ />•■ 


SEGMENT 


RW 




; Oefane 3lti3S S:&gni»nts iiiho.sa tru* 








8 CUP 


{7) 






oiC 










LOT.SEG 




ENCS 






; c oMniprab .' • : s Sia > u ( : ^ , iiit 


TSS.SEG 




SEGMENT 


RM 










DW 


8 CUP 


C?) 














! rooA oqq . ^ ; " 


TSS.SEG 




lEMDS 


















: C«t t'TT :on...j »uv s«. o «x 


lOT.SEG 




SEGMENT 


RW 






Bt b 


1, 'k ■• 


OW 


8 DUP 


C7> 


; fOl-'. ■'_<;■) -'JiWe -IKS* 




ti; -■ 


• 1 










*'■ 










IDT.SEG 




ENIHsc 






; t '><^*t> VTII cortuf 


GOT.SEG 


1 If. 


: • "j ! 

jSe^NT 


RH 












8 DUP 


C?> 




GDT_S:G 




ENDS 









(A 
-< 
(A 
H 

m 
S 

z 

> 
I- 



END 

ASSEMBLY COMPLETE, KD WARNINGS, ' Nf'iRRORS 



prgiim(^2: Dummy SkgmAHWfbr entp 



i«PX2S6 MACRO ASSEMBLER INITIAL 


TASK 






data 


PAGE 


1 


syst«ii-ID i»PX286 MACRO A3SEM3LER 


VX.y ASSEMBLY OF MODULE INIT_M00 










OBJECT MODULE PLACED IN :F1:INIT.0BJ 












AS^eiM&ig INVOKED BT: 


sfi:asM286.s« :fi:init.ab« 












LOC 


OBJ 


Line 


SOURCE 
















1 ♦! 
2 


*TITLE{'INITIAL 


TASK') 














3 


NA«E 


INIT.MDD 














♦ 

5 


EXTRN 


cat FAI! 














6 
7 


INIT.STACK 


STACKSES 10 















8 


INIT_D4T« 


SEGMENT RW PUBLIC 










0000 


???? 


9 


D4TA1 


DM 7 














1 


INIT_DATA 


ENDS 














1 1 


















12 


INIT_CODE 


SEGMENT ER 














13 




ASSUME DS:INIT_DATA 














14 














00 00 




15 


MESSASE 


DB 'Initialization ComplatsI t 


OHM A AH. n 










69TA61T4696F6E 


















20436F60T06C6S 


















746521 
















0018 


OD 
















0019 


OA 
















OOIA 


00 




















16 














0018 




17 


INIT.START: 












OOIB 


BEOOOO 


18 


NOV 


SI. OFFSET MESSAGE 










OOIE 


FC 


19 


CLD 












OOIF 




20 


MESS.LOOP: 












OOIF 


2EAC 


21 


LOOS 


CS:BTTE PTR CSI3 










0021 


OACO. 


22 


OS 


AL.AL 










0023 


T40S 


23 
24 


JZ 


INIT.EXJT 










0025 


50 


25 


PUSH 


AX 










0026 


9A0000 E 


26 


CALL 


CO 










99m 




2T 


JW 


MeSS_L80* 










0020 




28 


INIT.SXIT! 












002D 


F* 


29 


HLT 
















30 


















31 


INIT_COOE 


ENDS 










«*• HARNINS )LINE 


•31t SEGMENT CONTAINS rRIVILESCD INSTRUCTIDNS 


















Sm IN1T_START,0S:INIT_0ATA,SS: 


INIT_STACK 










miamm't m tmms 













Figure 10-3. Initial Task INiT 



IE «■ fci 



— . O * or* ■ 



a o 

O W J» 

♦ >• IJf 



er-or 



Binding and Loading 



■ CHAPTER 11 :- ->=^--v -..^a....... ' 

BINDING AND LOADING 

■ ?Ifu r Ifioigo' &c i/mir: -nnie'r ' . " .'r:n .lii';;irif; il. • irli :>?.u . 

Binding is the process of converting symbolic references into an implementation that the processor can 
utilize. The binding process spreads across many stages of software development, including source 
code, translators, binding utilities, loaders, and execution itself. Intel's program development tools include 
features that perform much of the needed binding. In some static systems no additional binding may 
be needed. In dynamic systems, however, you may choose to incorporate some binding functions in the 
operating system and related soft*aiHS iff arte to ^ate a style 'fe 
nature of your application. 

BINDING MODEL t 

To ensure that the binding process works correctly, it is a good idea to start with a model of the system 
i8tW!^we,foiii!*lirti^liehieve. A binding model includes these factors: 

• Modules — dividilg programming into compilation units 

• &gmentation — distributing instructions and data of modules among plifAWP^^^i^ grti. i t- 

• Interfaces — specifying the connections among modules 

• Naming — choosing names for modules, segments, and interfaces, avoiding ambiguity but promoting 
flexibility 

• TiMng — detePWMM.wlien to bind various types of syna^bdEc,^^^^ : 

As an example of a binding model, assume that the example modules presented in prior ehaptei^ 
constitute a complete operating system, called XOS, and apply each of these factors to XOS. 

Modules -.,i,,',r„- : -.■ V. .p, inrfosm -i'^ T 

The criteria used to separate functions into modules may include 

• Comprehensibility. Each module collects together functions that support a single operating system 
ccBicept of limited scope (for examplfe, aliases, synchronization). 

• Information hiding. Each rn^jile implemejits a data structure (for example, the alias lists in the 
ALIAS module) that you can manipulate only by calling the procedures defined in the module for 
that purpose. Other modules cannot access the data structure. 

• Independent development. You can choose modules so that each can be developed by a different 
programmer. Points of cooperation and communication among programmers include only the speci- 
fied interfaces among modules. Minimizing the number and complexity of interfaces reduces project 
administration costs. 

• Structured testing. Testing of the whole system is simpler when you cltS^ffi-'Siadlite sa'ti&t eaci 
can be tested by itself, before testing its interactions with other modules. 

• Flexibility. When you can anticipate changes to the system, you can limit the effects of the changes 
on other modules by isolating the areas of expected change in a module. 

Only the first Qf:t|^<iWia is; sigsifit^ 

design. i.,!}.- ^tb l->/-jl ; t..-)V. j-. ;<;■•- msj<>iq -.iB-.-nr m lovji O xii i,ti\ o 
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BINDING AND LOADING 



Modules are relevant to binding in that they (indirectly) define the units that can be distributed among 
physical segments. A module is-^ j^nek poiqpilatiQn .unit, divide each compilation 

unit into logical segments. Eacit'tcigk&iskiiahntMk mT^^ can be assigjiei to a physical 

segment. You can use the development tool Binder to combine more that one logical segment into a 
physical segment. 



Segmentation - 1-^^; u ., .r... 

f rot^ctiori re*i:plr.?ments,-pj^rt?ia%..flife^^l^ l^vf^ tp djstri^bute^^nqtiujps amon^ physical segments: 

• Data and procedures of different privilege levels must reside in different physical segments. 

• Data and procedures of one task must reside in different segments from those of other tasks unless 
sharing is explicitly intended. B^30%'i C MQUHS 

• , Instructions inuft reside.in .different physical segments f rpni ¥?ritabk data itsms., ; , ,j ^ r 

• Data structures for which you wish to provide individual protection (for example, thS' SttcSBj^^mm 
and mailboxes discussed in Chapter 5) must each be in a separate segment. 

Operating s0^^^c^imi^ ftot have: the same privilege level and are shared via the GOT can be 
combined in jtst ofie segment (assuming that the total size does not exceed 64K bytes). In fact, doing 
so has two advantages: all intermodule calls can be implemented as short CALL instructions, avoiding 
the additional processing associated with changing the contents of the CS register, and more GDT.-slot* 
are available for other purposes. Of the procedures in XOS, the level-zero procedures presented in 
Chapters 3 thru 5 can be combined in one segment, while the level-one I/O interface procediii;es cap 
go in another segment. Each device-driver task has its own code, data, and stack segments. 

Interfaces 

Possible mechanisms for implementing the interfaces among modules are ' luboM 

• Intrasegment (short) references. References to data or procedures in the same segment are most 
efficiently implemented when you can use the current contents of a segment register. 

• Intersegment (long) references. Referpnjees^-to 4^jt^ ot procedures in a segment not currently inj^^ted 
by one of the segment registers must cause a segment selector to be loaded into a segment r^isiter. 
rntersegment references permit sharing of ' fitnfeti^)fts snft)i^g fna^ 'toodutes^ and pernaff aifi^ t6 
fiinctions at another privilege level. ' ' ■ ' -' ''A 

• Sharing by value. Procedures and data can be shared by including a copy of the data or procedures 
in the same unit (segment or task, as appropriate) as each procedure that uses them. While this 
approach can yield more efficient execution in some cases, it has limited applicability. It is usually 

' best to share dynamically changing data by name, so that all the procedures that use it can obtain 
the most up-to-date version. Sharing large or widely used data or procedures by name uses main 
,-i memory-mete efficiently. 

• Sharing by name. The "name" referred to here is the descriptor of the shared data or procedure. 
Chapter 5 discusses methods of sharing by name (namely GDT, common LDT, and aliases). 

In XOS, all tasks share the segments of the kernel and I/O-interface segments via the GDT. Applica- 
tions procedures use long calls to acsfess the primitives in these segments. Calfe vfitlfih^the kernel level 
or within the I/O level to private procedures at the same level are short calls. 
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Naming WW.- ■ii.M: ..• 0'!r"-u ^'■. •/ ••i-.i.-v «!fiw.-jo.- . ..ihir/" h' I'jtoo n r 

The names by which you reference the components of a system influence the way the system can be 
boilnrf. Classes of natnes over v^kh you have some degree of control are • 

• Modules. Builder uses the name of a module to represent all publics or all segments within the 
' module. Debuggers use module names to qualify identifiers of variables and procedures. 

• ; J^ical segments. The choice of logical segment names determines the, possibilities for segment 
, , ,C(Hnbination. Binfief cpmbi;^^ lpg^| ^^gments that have the same name as well as compatible 

combine-types. 

• Physical segments. The names of physical segments give you theiftUlity !to<ia^igB segttWrt^ibut^ 
individually using the Builder. 

• Publics. Public identifiers must be unique among the modules that are bound together. 

• Gates. Gate names identify the entry points to procedures. You can use gate names to give entry 
points diffelcW fitt^ names than those used in the Source language. > 



Timing 

With respect to time, you can rate bindings on a scale running from early to late. An example of early 
binding is a compiler's assignment of segment-relative locations to procedures and data. The latest 
binding is that accomplished by the processor as it adds a segment-relative location to thg 24r^it .basp 
address of the segment. Between these extremes are other opportunities for binding: ' ' 

• Post-compile-time. Through Intel's utilities Builder and Binder, you can combine .s^iteiitSJfraGlve 
intersegment references, allocate descriptor table slots, and allocate memory. 

• Load-time. The loader can incorporate various levels of binding. i .(if . vid) o 

'a.' ff the object module contains fix-up informaiion'Ca'slri'a lffrkafele module), the loader can bini 
■'■ all references as it loads the segments Of a task. ■ '''i- 

'■1 J : - J 

- i<fe<4Tbe call gates pf the iAP^ 2§6 archits^cture make it ppssible for the loader to efficiently resolve 
references to predefined classes of procedures (to operating.systpfli primitives», |pr exfuapJe) at 
the time a program is being loaded. This ehtpter presents an example of this fotia ^ Imd-time 
binding in a later section. 

• Run-time. Call gates also permit binding to an executable segment at the time it is firs? ireiterehced. 
By resetting the present bit in a call gate to an unloaded segment, you ensure that a trap will occur 
whbn the gate is used. The "not present" trap handler can then load the required segment, allocate 
i Cescrtptpr fo*4|,,,;ai»d ^ y - . 



IIMPLEMENTING ACCORDING lN:$tMEl^^^^ 



With a binding model in mind, consider how to implement that model during the vadeUS-' stages of 
system development: in source eode, 'by t«aflslatOrsr by binding utilities, by loaders,'ipi|il#%erating 
systefcj and finaJtly^tf 4lie'proce»ititeeKi to .ioa- >• ; ■ ^r, j,, ;.;il.;ni vlioq/s '.u : 
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BINQINQ AND LQA0IN6 



The model behind the example operating system, XOS, includes these components: 

• Each module contains functionally related data structures and procedures. 

• One segiAent contains level-zero (kernel) procedures, another segment contains level-zero data, 
another segment level-one (I/O) procedures, and another level-^ne data. Operating system tasks 
(such as device drivers) have their own distinct segments. 

The GDT contains descriptors of kernel and I/O segments, making them sharable by all tasks. 
Gates for operating-system primitives, however, reside in the LDTs of the tasks that use them. 

• The segment names created by PL/M-286 set the standard for segment naming in general. (Refer 
to the chapter entitled "Linking to Modules Written in Ofh^'Eaa^pa.Sfes'' in the PL/M-286 User's 
Guide for definition of PL/M-286 segment names). 

»i Tasks will be loaded dynamically. 

• Load-time binding to XOS primitives is an option. (This is one reasoii fbif plicb^ gates for bperJ^dng- 
system pnsMtiyes in LJQTsi) c p i i ' 

SourceCode .. , . , ;, 

Since some of the logical segments declared in assembly language may be combined after assembly by 
the Builder, the assembler needs to know whether the object of an external reference will be in one of 
those segments whose descriptors it assumes to be loaded in segment registers. If the referraceis to 
another segment, the assembler must emit instructions that change the contents of a ^gment register. 
The programmer supplies this information via additional assembly language syntax. A variety of forms 
are available for this purpose, such as 

segment''^"""'' 

ASSUME 

NEAR and FAR variants of P R C and LABEL 
segmmtr;0verd)ies|for example ES:TABLE_ITEM) 

(Refer to the ASM286 Assembly Language Reference Manual for details on the use of these items.) 

The module DISP containing the dispatcher is the only kernel module of XOS written in assembly 
language (refer to Chapter 4). The logical code segment has the name NUCLEUS_CODE and combine 
type ER so that it will combine with PL/M-286 segments of the same name. This module has no logical 
data segment. The procedure DISPATCHER is a NEAR procedure because only other kernel p#bce- 
dures in the same physical segment call it. 

Compilers 

With PL/M-286, decisions regarding segmentation are not imbedded in source code but rather are 
implemented by the compiler according to compiler control statements that you supply. (Refer to the 
SMALL, COMPACT, LARGE, and extended segmentation controls in the PL/M-286 User's Guide.) 
With these control statements, you have nearly as much control over system structure as with assembly 
language, but changes in system structure do not require changes to source code. It is just as important, 
however, that use of these controls conform to a consistent model of system structure. 

Figure 11-1 shows the segmentation controls used for compiling the kernel modules of XOS. These 
controls define a subsystem ntaned NUCLEUS that contains all the PL-0 modules of XOS. The 
PL/M'286 compiler prefixes thei names of the code aiKl, data segments with the subsystem name. The 
list of exports intsludes aU the primitives. For each of the prei^tee».afti^4;ia:the li«^itke 
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' ■•'# ■0OfiFACT:-::$HtKriSOS<i«aS 

$ SLOT , POINT 

$ GATE , MEMORY 

S DISPATCHER , ALIAS 

$ SEMAPH , MAILBOX 

$ INTRUPT TASK ^ 

$ DESCRIPTOR , GATE' 

$ DISQUE , MESSAGE 

$ EXPORTS 

$ RESERVE_SLOTS 

$ ALLOCATE 

$ ,CREATE_ALIAS 

$ WAIT_SEMAPHORE 

$ SEND_MESSAGE 

$ CREATE_LDT 

$ L.OAD_LDT 

$ GET_GATE_PO INTER 

S ATTACH TO INTERRUPT 



RELINQUISH_SLOTS 
FREE_SEG 
CHANGE_AR 
SIGNAL^SEMaPHOI^ , 
RECEiVE_Mf S'SAfeE' ■ 
CREATE_TASK 
LQAD_LDT_GATE 

WAIT FOR INTERRUPT 



r 't''' Kit \r 



'ifimnq .iOX i-m '■>.'»■■' vri oJ s I'.i---; :v''' 



Compiler generates a long RET instruction at the end of the procedure or at RETURN statements^ 
This enables procedures in other segments to call the the kernel procedures. The keyword COMPACT! 
'^clls the compiler to generate short RET instructiotis for procedures not named in the export list. ; 



Binding Utilitl^ 

Intel's iAPX 2ii SiB&r (BND286)»an4%«impB«i4^ (9LEbM>:pix)vide a^»riety of binding serwces^ 

including ' ' -y^j^', | 

• Combining logical segments that have the same name and combine type j 

• Resolving references among modules I 
t Constructing templates for GDT, LDT, and TSSs | 
I i^Iocating memory fo r bootloadable portions pf the system I 



• Assigning a^^ i 



Ho sefl 
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* Constructing gatgs ' ' "~ -— — — j 

Formatting object files for the convenience of boot loaders and dynamic loaders | 
Creating export modules that contain gates for operating-^ystem interfaces ! 

Figure 11-2 shows the Binder specifications that combine the level-zero modules of XOS. The input 
modules contain only three unique segment names (the PL/M-286 names: NUCLEUS_CODE, 
NUCLEUS_DATA, and STACK): therefore, the output module contains just three segments: one for 
instructions, one for static data items, and one for the level-zero stack. The name of the output module 
is NUCLEUS; it is written to the file NUC.LNK. Similar specif ications combine the level-one modules. 
! ' - 

Figure 1 1-3 shows the specifications to build a bootloadable file for the example operating system. The 
SEGMENT statement assigns privilege levels to to each of the segments; segments not mentioned in 
khis clause rccMve privilege level 3 (PL 3) by defaillt. 



The TABLE statement defines the descriptor tables. The RESERVE clause allocates space for the 
working descriptors used by such modules as the memory-management module described in 
Chapter 3. The ENTRY clause identifies the remaining segment descriptors that belong in each table, 
puilder^l^tes slots for eactf oflH^di^^^rtptors. -^s . a^v ,• - w . 

The TASK statement provides mtotimihn for contracting TSSs. The identifier assigned to each task 

is ti e identifier of the descriptor of its TSS. The OBJECT clause identifies the module containing the 
information Builder can use to fill the segment-register and initial stack fields of the TSS. 

The GATE s^tement creates gates for each of the public procedures that are XOS prioiiti^, assigns 
a privilege level to each gate, and gives each a name different from the procedure name. 

The EXPORT statement creates a linkable module KERNEL in file XOS.EXP that application modules! 
»n use for bbidlttg to tfe gates for XOS primitives. j 

_ I 

■ ---^ - aiioqjta i».t rinS tot wiat8)(3dMa tF ft otagt^ ■ 



RUN :F2:BND286 & 

:F1: POINT. OBJ , :F1:SL0T.0BJ, & 

:F1:MEM0RY.0BJ, :F 1 : DI S P . OB J , & 

:F1:ALIAS.0BJ , :F 1 : SEMAPH . OBJ , & - y ^ • '■"••rstb: 

:F1:MB0X.0BJ , : F 1 : INTRPT . 08 J, & " " 

:F1:DESCR.0BJ , :F1; DISQUE . OBJ, & 

PLNase.LiB & 

NAME (NUCLEUS) OBJECT ( :F1;NUC. LNK) NOLOAD DEBUG 

'in/! J .iH,i!j.'4 Dr.s V-ri'-.H imii^ r : ■■ 



;t\:>-^/. j . 7ry: i '' . t,,. ■aha'- v.- ■ ' , . 

FIgurs 11-2. Binder Sf>ectflca«on8fQri^{0@JCwri|«i a, . -v;. § : , • 

tt-ffl 12198(W)01 



BmfMNQ.;ANrLOAOIN@ 



system-ID iAPX286 SYSTEM BUILDER, Vx.y 

INPUT FILES: :F1:N0C.LNK, :F1 : ORTASK. OBJ, :F1:CONSOL.OBJ, :F1 : LOADER . LNK, 

:F2:LARGE.LB2, :F1 : STACKS . OBJ 
OUTPUT FILE: :F1:X0S 

CONTROLS SPECIFIED: TITLE (Example O.S.) BOOTLOAD BUI LDFILE ( :F1 : XOS . BLD) 
OBJECT ( :F1:X0S) 

BUILD Fits':' ^i^iTOS.BLb' ■ 



1 

2 

3 
4 

5 
6 

7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 



EXAMPLE_OS ; 

SEGMENT 

NUCLEUS_CODE 
NUCLEUS_DATA 
NUCLEUS. STACK 
' ' URTASK_CODE . . 
URTASK_DATA 
URTASK. STACK 
LQ_PLM2 86_LIB_CODE 
LARGE_V1P0. STACK0 
LARGE_V1P0. STACKl 
LARGE_V1P0. STACK2 
CONSOLE_DRIVER_CODE 
CONSOLE_DRIVER_DATA 
CONSOLE_DRIVER.STACK 
CONSOLE_STACK0 
LOADER_STACK0 

GATE 

XQ_ATTACH_TO_INTERRqPT 
XQWA I T_FOR_I NTERRCi^'l' 
XO_RESERVE_SLOTS 
XQ_RELINQUISH_SLOTS 
XQ_ALLOCATE 
XQ_FREE_SEG 
XQ_CREATE_ALIAS 
XQ_CHANGE_AR 
XQ_WAIT_SEMAPHORE 
XO_SIGNAL_S EMAPHORE 
XQ_SEND_MESSAGE 

, . XQ_RECEIVE_MESSAGE 

^ XQ_CREATE_LDT 
XQ_CREATE_TASK 
XQ_LOAD_LDT 
XQ_LOAD_LDT_GATE 
XQ GET GATE POINTER 
K\h.\ #<iMBi_8WSgI%=NTERRUPT, 



(DPL=0), 
(DPL=0) , 

(DPL=0, LIMIT=+20) , 

(DPJ[,=.0,) ^.^ . . 

(DPr,'=0-) , ' 

(DPL = , LIMIT=+20H) , 

(DPL = 0, CONFORMING), 

(DPL = 0) , 

(DPL=1) , 

(DPL=2), 

(DPL=1) , 

(DPL = 1) , 

(DPL = 1 , LIMIT=+20) , 
(DPL=0 , LIMIT=+20) , 
CDPL=0, LIMIT=+20); 



tENTRy=ATTACH_TO_INTERRUPT , 

(eNTRY=WArT_FOR_INTERRUPT, 

{ENTR Y=RES ERVE_SLOTS , 

(ENTRY=RELINQUISH_SLOTS, 

(ENTRY=ALLOCATE, 

(ENTRY=FREE_SEG, 

(ENTRY=CREATE_ALIAS, 

(ENTRY=CHANGE_AR, 

(ENTRY=WAIT_SEMAPHORE, 

(ENTRY=S IGNAL_SEMAPHORE, 

(ENTRY=SEND_MESSAGE, . 

(ENTRy=RECEIVE_MESSAGE, 
(ENTRY=CREATE_LDT, 
(ENTRY=CREATE_TASK, 
(ENTRY=LOAD_LDT, 
(ENTRy=LOAD_LDT_GATE , 
(ENTRY=GET_GATE_PO INTER , 
DPL=0, ENTRY=TIMlNT) ; 



( a 



DPL=1) 
DPL=1) 
DPL=3) 
DPL=3) 
DPL=3) 
DPL=3) 
DPL=3) 
DPL=3) 
DPL=3) 
DPL = 3) 
.ajJEa.=3) 
DPL=3 ) 
DPL=3) 
DPL=3) 
DP£.=3) 
DPL=3) 
DPL=3) 



TABLE 

GOT (RESERVE= (4 . . 9) , ENTRY= ( 
NUCLEUS_CODE, 
NUCLEUS_DATA, 
NUCLEUS . STACK, 
LQ_PLM2 8 6_LIB_CODE, 
LARGE V1P0. STACK, 



I TO J bn: 



Figure 1 1-3. Builder Specifications for XOS 
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47 

48 

49 

50,, 

51-- 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 



LARGE_V1P0.STACK0, 
LARGE V1P9..STAPK1, 
LABteE'"Vlt>i. STXCK2 



) , 



) 



URTASK_LDT (ENTRY= (URTASK) ) , 

CONSOLE_LDT (ENTRY= (CONS0LE_DRI VER , CONSOLE_STACK0) ) , 
LOADER_TASK_LDT (ENTRy= (LOADER , LOADER_STACK0 ) ) , 
IDT <ENTRY=(15:TIME SLICE)); 



TASK 
ADAM 



(INITIAL, 



OBJECT 
LOT 

CONSOLE_DEVICE (OBJECT 
LDT 

STACKS 
(OBJECT 
LDT 

STACKS 



LOADER TASK 



URTASK, 
URTASK_LDT) , 
CO[JSOLE_DRIVER, 
CONSOLE_LDT, 

(CONSOLE_STACK0) ) , 
LOADER, 

LOADER_TASK_LDT , 
(LOADER_STACK0) ) ; 



EXPORT #:F1:X0S.LB2 (KERNEL ( 
XQ_RES ER VE_S LOTS , 
XQ_RELINQUISH_SLOTS,, , 
XQ_ALLOCATE , ' " 

XQ_FREE_SEG, - - „,,,. 

XQ_CREATE_ALIAS, ' "" 
XQ_CHANGE_AR, 
XQ_WA I T_S EM APH ORE , 
X Q_S I GN A L_S EM A PH OR E , 
XQ_SEND_MESSAGE, 
XQ_RECEIVE_MESSAGE) ),; 

E^ , ■ : 



BUILS FILE PROCESSING COMPLETED 



^ure 1 1-3. Builder Specifications for XOS (Cont'd.) 



These specffications do no} illustFate all the features of Sttilider, refer tithe iAPX 286 System Buildef^ 
User's .GmHe for a eoi^lete descrijrtion of Builder syntax. j 



OVERVIEW OF LOADING 

Jhe loader in a dynamic system is not only rcspoasible for copying a program into main memory, but 
is also a step in the bindiiig process. A loader installs the actual TSS and LDT for a task, thereby 
tnaldng it possible for the processor to interpret the task's memory references; i 



If all symbolic references are already resolved, a loader's work is simple. The iAPX 286 object module 
format (OMF) organizes segment information to facilitate rapid loading with little decision-making 
the loader program. ac"*' i-^t ?r -^i+r.: '":io«ii8 isbltwfi .f.'-rr oiupH 
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Cdniverting« Prdgrdm Into a Task - 

'■'.nr.rii i ■ j ■•5ft i HvC : - ■ 

Before an operating system can switch control to a new task, these structures must be initialized: 

• The TSS (data the processor needs in order to run the task). • .■ 

• The task database (TDB) (data the operating system needs in order to run the task). 

Either the following structures ingsf tHe jpresent^^^^^ 

present when necessary: ■ t',! ? T 

• Stack segments for each privilege level at which the task runs, (A sta(;k-fau|^|lM^j|^^uld 
automatically allocate a stack the first time it is used.) ' 

• Executable and data segments. (A virtual memory system could make these pi'esent when referenced.) 

Most programs also need an LDT to contain descriptors for segments private to the task. An LDT is 
not required, however, if all descriptors used by the task reside in the GDT. 

t. yr - 

The initial values in the CS:IP Helds of the TSS should point to the entry point of th6 first ftrdcedure 
of the new task. 

STYLES OF LdWit^ Je.Tno=i aJuboM )3e/_ )8? "^i 

There are several ways to structure a loader. The following are just a few examples:' ''"''^ " ' 

.M..i,^..i .. ..u. .,-..*.„ I'.ii esiJiSiru mi -t 

1. As a separate and permanent task. With such a structure the loader constructs data segments in 
the format of the new task's TSS and LDT. To create the new task, it pasises descriptors for these 
segments to privili^e-level (F'L^)) ffrbcfedures that eonveft them to syste^^^e^eoi^^^^^art 
the new task. 

2. As procedures that run within an existing task. This approach suits the UNIX EXECUTE function, 
where the FORK function creates the task in which the loader runs as a duplicate of the task that 
called the FORK function. The loader deletes the descriptors it finds in the task's LDT (thereby 

'■ deleting the associated segtt^6'^tIAl^'alia^ieJ[ki«lei'Jc>t^«^j£g|:Mld^(^tes new descriptors 

for the segments it loads. 

3. As procedures in a skeletal task created by the operating-system kernel. The loader has only to 
allocate an LDT and install descriptors for the segments it loads. 

For approaches 2 and 3, the procedures of the loader may have segment descriptors and gates in the 
GDT so as not to encumber the LDTs. 



KERNEL SUPPORT .u, .b:,b^^\ <.< id, ... oar 



A loader normally runs at PLs 2 or 3 because it uses of both kernel-level procedures (for example, 
ALLOCATE to create a segment for the new task) and PL-1 procedures, (for example^ the I/O proce^ 
dures to read object modules f^M^iMii^;' WvtiW^i t&^'e^ti^liMllWsdMe^^ 
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PL-0 procedures can execute. For these functions the operating system must provide some additip^al 
support. These functions include 

• Changing the access rights byte of a descriptor. The loader can create a writable data segment 
(using a level-0 procedure such as the ALLOCATE procedure described in Chapter 3) into which 
to read a segment from the object file of the program being loaded. But, if that segment is to have 
some other type in the new task (the segment might be an executable segment, for example),4he 
access rights byte must be changed. 

• Filling the new task's LDT with the base addresses of its segments. When the loader allocates a 
'" segment for the new task, the ALLOCATE procedure places the physical base address of the seginent 

in a descriptor table (presumably the loader's LDT, but possibly the GDT). Only PL-0 procedures 
should have aeeess to physieal addresses in descriptor tables. 

I-.' 

• Allocating the stack segment for PL 0. Insufficient space in this segment can cause failure of PL-0 
procedures. Also, if the kernel requires the TSS to be located in the PL-0 stack segment (as suggested 

( i ,ft!iG^ptef»t)v ib©B the kefnel' thotM-hajidle tJie-esMpteieities <rf sett«g s»efc i.=sfrBS*B»e- ' -= H « 

• Initializing the task database (TDB) for the new task. Only PL-0 procedures have access to this 
yi diata structure. (Refer to Chapter 4 for a discussion of the task database.) 

• Entering the new task in the scheduling queues and setting the back-link and nested task flag in the 
new TSS. These operations are crucial to proper functioning of the scheduler and therefore should 
be done at PL 0. . i , r; : ^li 




iAPX 286 Object Module Format 

Intel has defined object fliojiulie formats (OMFs) for the iAPX 286 to be, usa^dj 
program utilities, and loaders. There are two classes of object module: 

• Linkable modules, which are produced by translators and consumed by Builder and Binder. Binder 
"I can also produce a linkable module from one or more input linkable modules in a process known as 

Mreiheritmmming. ' '■ - ' ' " ' ' ' \" ' 

" Ji,r.: ■■■>:i 

• Loadable modules, which a?e produced by the Binder and the Builder and coasu»rf by loaders and 

'■ .' . f. ..br.ti I! I'v-'-;. •.•fi( ; - jL ■ioii-i>H >u ( <: .••••5 ■''^l'>'^ .: 

Refer to the idPMJM §fm^'S^Mm<lMp!»^^tM.^iislmieAd&fmtiom^ of the iAPX 286 Object 
Module Format. 

Loaders that adhere to Intel's 0>4|[^ for \o^L(\2^e^^^.^^^l^&J^s^^ j^ntel's 
program development tools. There are two basic variations of tfie iAlPX 286 OMF for lottiable modules: 

• That created by the Binder supports straightforward, single-task modules. 

• That created by the Builder supports more complex variations, including multitask modules with 
shared segments (possibly including shared LDTs), reserved LDT locations, GDT descriptors to be 
installed as the task is loaded, etc. , ; , : j., 

Builder not only produces modules intended for use by dynamic loaders but also produces bootloadable 
modufes. designed for use by bootstrap or initializing loaders. Bootloadable modules use absolute 
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The OMF of each object module consists of a heaiierr&llowed by a sequence of sections of various 
kinds. The secticms rdevant to this discussion are thoM in loadabfeBiocbdesiliacludlb^. 

• DESCRP: contai^'^i tiie dftscriptors fo^ tfie module.' loader can use this section as a template 

for the LDT. 

• LODTXT: contains the data and instructions to be loaded. A loader fills allocated memory segments 
from the records erf LODTXT. ' ' =-£;c? ^irti 

• DESNAM: provides symbolic names for segments. A loader can use these symbolic names to provide 
a load-time interface for making changes to segment parameters (for example, decreasing segment 
limit of an expand'^wn stack segment to provide more stack space). 

FloW'Of LoacleiriJi;Tj'/ -i-J . -i . x , ... ....<',.- 

A 'loader must take different action depending on whether the loadable modules are created by the 
Binder or by the Builder. The main difference in loading the two types of OMF is the source of infor- 
mation for descriptor tables. In the case of Binder OMFs, the DESCRP section is in the format of an 
LDT. In the case of Builder-created OMFs, information for the GDT, IDT, and LDTs comes from 
various LODTXT records. A Boolean initMlteadei' of a ioa<yble;iiiodule distinguishes between Builder^ 
created and Binder-created modules. 

FLOW FOR BinnitEfKSREATED MODULE 

1. Allocate space for LDT segment. The size of the segment is eight times the value of tbe descriptor 
count field of the module header. Put LDT descriptor in, GDT, - ij on" no<}/^ ' 

2. Read the DESCR section into the LDT segment. ' ' ' ""^ 

3. < Allocate space ror all segments specified in the LDT, updating the b^^addresSrHeids. • . : 

4. Allocate space for the TSS. (Step 3 does not allocate the TSS because the DESCR section does 
. , , not contain a TSS descriptor.) Put TSS descriptor in GDT. 

5. 'i«.Md first IjODTXT section into TSS segment. (The first LODTXT recwd is always a TSS;) 
^.-'l^LDTseleci^^ikqTSS; " ,/ ^.^i'Um^^"!^ 

7. If the LODTXT section is exhausted, the task is completely loadedi Jttaipritatke TSS. jaO. r< 

8. Read next LODTXT record into proper segment. Go to step 7. 



FLOW FOR BlilLDifCREATED MODULE 



-r bnirl I.,. 



1. Allocate tempofitry space to hold all entries from the DESCRP section. 

2. Read the DESCRP section into this space. rtSQAC: ~ V } 

3. Allocate physical segments for all DESCRP entries (except for gates). 

4. Read beginning of LODTXT record. 

5; Examine descriptor name of LODT5P^>S4fioid. llie MettOf niatlfte B identifier for 

the GDT or IDT, or it is an index into the DESCRP entries. The type field of a DESH^IP entry 
distinguishes LDT segments from other types. 

■ , a. If the LODTXT record defines entries of the GDT, then, for each entry in the record, obtain 

the descriptor from DESCRP and installit in the GDT. 

b. If the LODTXT record defines entries of the IDT, then, for each entry in the record, obtain 
rjftedeS«i|»t*JromDESaaFaMu«staUiti% il/ _iflJ_f!AUJ ,,! j 
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I! c.. If the LQsDTXT lecord define an LDT, then, for each mtry in the record, obtain the descrip- 
tor from'^MSSC».aiW>iiM!«it:iBithe M)Ti ^^■ ^ /..rj?'L ^ , ' -r ■'^r[^ 

d. If the LODTXT record does not apply to a descriptor table, re^d the LODTXT record ^ifpctlx 
into the selected segment. i 

6. If more LODTXT records remain, go to step 4- 

7. Free the space used for DESCRP entries. r /iTii j r • ■ - " r-- 

8. The task or tasks are loaded. Jump to the TSS identified in the module header. 

LOAD-TIME BINDING 

As with any system, it is possible on the iAPX 286 to delay many binding operations until load time 
by incorporating binding functions into the loader. The call gates of the IAPX 286 architecture, however, 
provide an especially convenient and efficient way to delay one specific binding operation: namely, 
binding of calls to operating-system primitives. Load-time binding to operating-system primitives is an 
advantage when 

• Th«f I operating system is uiider developmenf, and GDT locations of operating-sy^em s^ment 

descriptors are subject to change 

• Programs may execute under different operating systems that have different GDT layouts 
Data structuies for implementing load-time binding are 

• An export module of specially marked; dummy gates for operating system primitives. Figure 1 1-4 
shows how you can create such a module through Builder specifications. The NOT PRESENT 
specification marks the gates by resetting the present bit. Gates used for this purpose must reside 
in the LDT so that Binder (which works only with LDT descriptors) can use them. You need to 

, J, lyjd^te this- expert fjlfi ojily y/hsa you change the number or names of operating-system gates,' 

• A table of actual gates for the operating-system primitives. This table must contain, for each primi- 
tive, the gate name, a GDT selector for the segment in which the primitive resides, and the entry 
point (offset) within the segment. It is most convenient to take such information from a Builder 
export file that exports the gates for operating-system primitives. The example specifications shown 
in flgureflt-3 ceeatecpiBfa aB'«^rt'fiei;'i:<^ J ; f -' l .; j .r-\; • no... <' ' li i 

Figure 11-5 shows the data flow for load-time binding. By using the gate name from the DESNAM 
section, the loader associates a marked gate in the LDT with its gate name. Given the gate name, it 
looks up the actual binding information. BJUOOBI 03TA3a'>-< ii. a r ^ WOJ'^ 

EXAMPLE LOADER -^(i J'h nuii-.s* l.vi jfe!../ , 

Figure 11-6 shows an example of a loader that reads the iAPX 286 OMF, resolves references to 
operating-system primitives, and calls kernel procedures to create a new task. In the interest of simplic- 
ity, tl)is exapiple recog^^e^ only, the siifJiftaslSiiQMF ppdn^ed by the Binder, and all error checking 
is,OBaitted... .oi'l tjqvi ariT .vn,.-:. y<- 

This loader calls the kernel procedures CR,EATE_LDT, LOAD_LDT, LOAD_LDT_GATE, 
CftEATE_TASK, RESERVE_SLOTS, and ChXn6E_AR, which are not shown. CREATE_LDT 
allocates an LDT segment for a new task and installs its descriptors in two of the four GDT slots 
specified by TASK_SEL. LOADJLDT transfers a descriptor from the LDT of the loader to the LDT 
of the new task. LOAD_LDT_GATE jdaetsta gate ih the IiDTat>ft«'.Jiew ta*..CREATE_TASK 
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system-ID i&SX286 SYSTEM BUILDER, Vx.y 
INPOT FILES: :F1:NUC.LNK 

OUTPUT FILE: (none) . 
COHTROLS SPECIFIED:/ TITt^taettes^or Load-Time Bin#lngfe_,jK}RQOfB^D NOOBJECT 
BUILDFILE( :?1 :XOSGAT.BLD) PRI}h^f^J^liJC0SSM<|JP2) 

BUILD FILE: :F1:X0SGAT.BLD ' 



1 
2 

3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 



EXAMPLE_OS ; 

SEGMENT NUCLEUS_CODE (DPL = 0), NUCLEUS_DATA (DPL = 0) 
NUCLEUS . STAQK (DPL = ) ; 



GATE 

XQ_RESERVE_SLOTS ,(ENTRy= 

XQ_RELINQUISH_SLOTS {ENTRY= 

"XQ_ALLOCATE {ENfTHXs 

{Q^FREE_SEG (ENTRy= 

|!CQ-ijeRB*S'SiALIAS . (ENTRY= 

J5®~_CHANfjg^AR (ENTRY= 

xq_wait_semaphore (entry= 

xq_signal_semaphore (entry= 

xq_send_message (entry= 

xq_recei*i^messa6e (ENTRY= 



RESERVE_SLOTS , 
RELINQUISH_SLOTS , 
ALLOCATE, 
^BREE SEG, 

cre&'te_alias, 

CHAffcE_AR, 

wait_semaphore, 
s ignal_semaphore, 
send_message, 
receive message, 



DPL=3 , 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3, 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3, 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) , 


DPL=3 , 


NOT 


PRESENT) ; 



TABLE 

GDT (ENtRy=(NnCLBUS_CODE, NUCLEUS_DATA, NUCLEUS . STACK) ) , 

DUMMY (ENTRY= ( 

XQ_RESERVE_SLOTS , 
XQ_RELINQUISH_SLOTS , 
XQ_ALLOCATE, 

XQ_FREE_SEG, 
XQ_CREATE_ALIAS, 

XQ_CHANGE_AR, " 
XQ_WA I T_S EM APH OR E , 
XQ_S I GNAL_S EM APH OR E , 
XQ_SEND_MESSAGE, 
XQ_RECEIVE_MESSAGE) ) ; 

EXPORT #:F1:X0SGAT.LB2 (KERNEL ( 

XQ_R ES ER VE_SL0TS , 
XQ_RELINQUISH_SLOTS, 

XQ_ALL0CATE, 

XQ_FREE_SEG, ~ 
XQ_CREATE_ALIAS, 
XQ_CHANGE_AR, 
XQ_WA IT_SEMAPHORE, 
XQ_S I GN A L_S EM APH OR E , 
XQ_SEND_MESSAGE , 
XQ_RECEIVE MESSAGE)); 



END 



BUILD FILE PROCESSING COMPLETED 



•jui) br,! 



11-13 



121960-001 



BINDING AND LOADING 




' 121960-55 

fl(ur« 11'S. Strategy for Load-Tilne'Brnding' \l 

.' (, 

I 

I'inishes creation of the new task by creating a TSS from a template in the loader and placing thp new 
task in the scheduler's queues. RESERVE_SLOTS uses techniques such;,wi; those illustrated iri 
Chapter 2 to allocate descriptor table slots. CHANGE^R is used to place the iWES*et, type code intd 
the writable data-segment descriptor used by the loader to fill a sejgMent. 2?sff-ic»*m riej 

I j 
|rhe module BOND (shown in figure 1 1-7) shows the handling of the table of actual gates for operate 

i^-system primitives. The procedure GET_LOAD_FILE is not defined here. It simply fetcte..tke>£ile 

specification for a loadable iaQdideJEom,.for example^ the eonsdle or-thevPCHnmand line interpreter. 
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^^/'^-2%C0HPiLER 960-515 ^f^^aae -aj . «cPA<f^ -K^^iq 

system-ID PL/M-286 Vx.y COMPILATION 0F .fW^QSJS, , ny, , j 

OBJECT MODULE PLACED IN :F1: LOADER. OBJ 

COMPILER JNJiftyCEQ!,. BY: JPLM286. 86 : Fl : LOADER . PLM DEBUG 



$ PAGEWIDTH(71) TITLE (' 960-515 ') . . . , - 

$ INCLUDE (:Fl:NUCStJB.PI.H) ' '^ _' 'J^- !• 

S NOLIST 

$ INCLUDE (:F1:UDISUB.PLM) 
= $ NOLIST 

$ COMPACT 

LOADER: DO; 

******************** ***•**'****************■* ********** ^ 

X- „pKCLARE BOOLEAN, LITERA;,I.Y 'BYTE', , 

.^■Xl -M-.K' FALSE ' LiTBRftfitY '0', 

TRUE LITERALLY '0FFH', , , 

TOKEN LITERALLY 'WORD', ' " 

CONNECTION LITERALLY 'TOKEN', ' " ' 

„„„ OFFSET LITERALLY 'WORD', 

, >l_ja. fOREVER LITERALLY 'WHILE TRUE'; 



I 



3 


1 


4 


2 


5 


2 


6 


1 


7 


2 


8 


2 


9 


1 


10 


2 


11 


2 


12 


1 


13 


2 


14 


2 


15 


1 


16 


2 


17 


2 


18 


1 


19 


2 



/* Externals */ 

RES ERVE_SLOTS : PROCEDURE (TABLE , COUNT , SLOT_PTR , EXCEP_PTR) 
EXTERNAL; ' ^ 

DECLARE TABLE WORD, COUNT WORD, ( SLOT_PTR , EXC EP_PTR ) 
POINTER; 

END RE^ERVE_SLOTS; ' ^ 

CHANGE_AR: PROCEDURE ( S LOT , RI GHT S , EXCEP_PTR ) EXTERNAL; 
DECLARE SLOT SELECTOR, RIGHTS BYTE, EXCEP PTR POINTER; 
END CHAHGE AR; t : .7r. . i- 

AttOCATE: PRdcfiBfiSE ' (SL^T ,'SlGHT^ j ^igEyfeXCBl' PTR) ' '• 

EXTERNAL; •/■ '•vi 1- 

. JPECLARE SLOT SELECTOR, RIGHTS BYTE, SIZE WORD, 

■■''S;XCEP_PTR POINTER; 
END ALLOCATE; 

FREE_SEG: PROCEDURE (SLOT, EXCEP_PTR) EXTERNAL; 
DECLARE SLOT SELECTOR, EXCEP_PTR POINTER; ' 
END FREE_SEG; 

CREATE_LDT: PROC EDURE ( TA S K_S EL , S I ZE , EXCEP_PTR ) EXTERNAL; 
DECLARE TASK_SEL SELECTOR, SIZE WORD, EXCEP PTR POINTER; 
END CREATE LOT; 

I.OKb_LDT: PROCEDURE (TASK_SEL, NEW_SLOT'r''^iD! SLOT, . 

EXCEP_PTR) EXTERNAL; .a.-ZaT- . - 

DECLARE (TASK_SEEi; NBW_SL0T, OLD^SCQ'SI^SELECTOH, ^ 

EXCEP PTR POINTER; .*3^?.»00 TWT £ S5 
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PL/%h2jM5 COMPILE Seg-Sl? date PAGE 2 

m i mo L<MSj)^ }■-''' "'"^ 

21 1 I,0&D_LPT_GATE : PROCEDURE (TASK_SEL, NEW_SLO'* ''fil'<SHTS^'"^ ' 

TARGET, COUNT, EXCEP_PTR) EXTERNAL; 

22 2 DECLARE (TASK_SEL, NEW_SLOT) SELECTOR, RIGHTS BYTE, 

tTARGET, EXCEP_PTR) POINTER, COUNT BYTE; 

23 2 END LOAD_LDT_GATE; 

24 1 CREATE_TASK: PROCEDURE (TASK_SEL, TEMPLATE, PRIORITY, 

EXCEP_PTR) EXTERNAL; 

25 2 DECLARE TASK_SEL SELECTOR, (TEMPLATE, EXCEP_PTR) 

POINTER, PRIORITY BYTE; 

26 2 END CREATE_TASK; . f 

27 1 GET_LOAD_FILE: PROCEDURE ( FX LE_S E^_.B'BR).- ,BX1SERNAL; 

28 2 DECLARE FILE SPEC PTR POINTER; , 

29 2 END G#t'_i;6AB3FILET""" ' 

30 1 B0ILD_BOND_TABLE: PROCEDURE (FILESPEC._PTR,' «CCEP_PT!^) 

EXTERNAL; 

31 2 DECLARE (EILESPEC_PTR, EXCEP_PTR) POINTER; 

32 2 END B0ILD_BPND_TABLE; 

t3 X FIND_BOND: PROCEDURE ( S NAf^E_PTR„. :i(ni'Y_PTR , SEL_PTR, 
EXCEP_PTR) EXTERNAL; i - ■ . . 

34 . .a . . . DECLARE (SNAME_PTR, ,ENXa;5L*m» .45?^'W« ,R15GPP_PTR) 
■\ POINTER; 

35 2 END FIND_BOND; 

3« Ir INITIALIZE_SYSTEM: PROCEDURE EXTERNAL; ' 

37 EJ>D, -IJIITIALIZE_SYSTE^;..- , , a. ^r.'.. .30 ^ 

38 1 REPORT: PROCEDURE (EXCEP_PTR) MTff^'tg j ' 

39 2 DECLARE EXCEP_PTR POINTER; 

40 2 END REPORT; . 

41 1 DQSATTACH; . ,--^y^ 

PROCEDDRE (PATH$P, EXCEP$P) CONNECTION EkTERNAL; 

42 2 DECLARE (PATHSP, EXCEPSP) POINTER; 
f3 2 END DQSATTACH; 

44 1 DOSDEjAdH: PROCEDOfiE (dbs^„ , EXCEPSP) EXTERNAL; ' 

45 2 DECLARE CONN CONNECTION, "EXCEP$P POINTER; , , 

46 2 END DQSDETACH; 

47 1 DQSOPEN: ' ' 

PROCEDURE (CONN, ACCESS, NUMSBUF, EXCEPSP) EXTERNAL; 

48 2 DECLARE CONN CONNECTION, (ACCESS, NUMSBUF) BYTE, 

EXCEPSP POINTER; 

49 2 END DQSOPEN; ' ' 

50 1 DQSSEEK: PROCEDURE 

(CONN, MODE, LOCATION, EXCEPSP) EXTERNAL; 

51 2 DECLARE CONN CONNECTION, MODE BYTE, 

^ LOCATION DWORD, EXCEPSP POINTER; , ^, 

52 2 Etib DQ$SEEK; - , t ' ' 
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53 1 

-.54 ^MC? to 
55 2 



56 
57 
53 



I'' 

2 



QQ$ftJS^DlS PROCEDURE 

(cbllM, BUFSP, COUNT, EXCEP$P) WORD EXTERNAL; 
0ECL;V^ conn CONNECTION, COUNT «ORDVj i > 

(BUF$P, EXCEP$P) POINTER; OSC 
END DQSREAD; 

DQ$C:LOSE: PROCEDURE (CONN, EXCEP$P) EXTiERNAL; 
DECI^ARE CONN CONNECTION, EXCEP$P POINTER; 
END DQSCLOSE; 



/* ' Data 



59 



V • toin i 



60 



61 
62 



DECLARE IN_GDT LITERALLY '0', 

IN_LDT LITERALLY '1', 

DATA_W LITERALLY VllUCi010B", /* Access rights: 
present, DPL=3, expan4-up, writable, data segment */ 

DATA_WD LITERALLY '111101108', /* Access rights: 
present, DPL=3, expand-down, writable, data segment */ 
^; -J READ LITERALLY '1', 

DEFAULT_PRIORITy LITERALLY '4', 

ALLOCATED ^.^RBALLY '80H', 

OK LITERALLY ' ' , 

EXCEPTION LITERALLY 'EXCEPOOK'; 

DECLARE PATH_NAME (47) BYTE, /* D^S,Ij Jile tO load */. 



LOAD_FILE 
ACTUAL 
EXCEP 
T«,SK_SLOT 

DCS SEL 



CONNECTION, 
WORD, 
WORD, 

SELECTOR, /* 



SEIrSaTOR 



BOND_FILESPEC (*) BYTE 
INITIAL (11, ' :F1:X0S.LB2' 



First of GDT slots 

for new task */ 
Data or code segment 
of new task */ 

); 



<4 



DECLARE FILE_HEADER BYTE; 



declare module_header 
total_space 
^ , descr count 
-built" 

DATE 

TIME 
CREATOR 
, ., - ^„ TSS_SEL 
■ " ^ DESCRP_LOC 
LODTXT_LOC 
IGN0RE_1 
DESNAM_LOC 
IGN0RE_2 
IGN0RE_3 
IGN0RE_4 
'•■ " LAST_LOC 
RESERVED! 



STRUCTURE ( 
DWORD, 
WORD, 
BYTE, 

6yte, 

BYTE, 
BYTE, 
WORD, 
DWORD, 
DWORD, 
DWORD, 
DWORD, 
DWORD, 
DWORD, 
DWORD, 
DWORD, 
, DWORD, 



12196(M)01 



BINDING AND.LOADUIG 



S'L/^M■«« COMPILER 98Bt515 2-!?die& >>2^:Wr t^^^ .l"^ 



RESERVED2 DWORD); 

/* Table of segment names from DESlii&f'SSftion of -OMP **/ 

63 1 DECLARE DESNAM_SEL SELECTOR, 

DESNAM_WIDTH LITERALLY '41', ' ' 

DESNAM BASED DESNAM_SEL (2) STRUCTURE ( 
;J.;i; 3TX3 "4Bt*(E-(DB8mM WIDTO) BYTE ), ' 

;irar"Tr^tof^q,-,X^ '-^dSiy;-"""'/* index V ^ ' 

/* RAM copy of DESCRP section of OMF */ 

64 1 DI^LARE DESCRP_SEL SELECTOR, 

" *■ ' SEGDT BASED DESC RP_SEL 'fzl' *#rRtK?(t>RE ( 

LIMIT WORD, 
LO_BASE WORD, 

HI_BASE BYTE, /* Data/code segment descr */ 

RIGHTS BYTE, 

RESERVED WORD ) , 

GATET BASED DESCRP_SEL (2) ST^iUCTURE ( 
" ' '-' -iftijii POittT OFFSET, 

■ V- .-■ ' -SEt - ' • SELECTOR, 

• ' ' ' WORDjCOOTIT BYTE, '/f "Gate descriptor */ 

• ■ RIGHTS - ' byte, ""y 

RESERVED WORD \ ) , 

LIX WORD; 'V* Index */ 

/* Template for Task State Segment for new task */ 
■'''1" DECLARE TSS STRUCTURE ( ' ■•■ 

BACKt SELECTOR, 
SP0 OFFSET, SS0 SELECTOR, 
SPl OFFSET, SSI S5LEGT08|L 
SP2 OFFSET, SS2 SI^C^MJ 
IP OFFSET, 
' ; ' " • FLAG WORD, 

(AX, CX, DX, BX, SP, BP, SI, DI , 
ESi^ -eS, ^SS, H|Si EibTj.f#*i) SELECTOR ); 

/*******************************************************/ 

/* Subroutines . | , 

66 1 SECTIONSIZE: PROCEDURE (TOCIX) DWORD; 

67 2 DECLARE TOCIX WORD; /* Index into Table of Contents */ 

68 2 DECLARE T0C(8) DWORD AT ( @MODULE_HEADER . DESCRP_LOC ) , 

IX WORD; 

/* Find the size of an OMF section */ 

69 2 DO IX=T0CIX + 1 TO 7; 

70 3 IF TOC(^X)<>0 /* Skip.bY OUjl gections */ 

71 3 THEN RETURN TOC (IX) -fisei wix>'; 

72 3 END; • - ' 

73 2 ' END SECTION_SIZE; 



..--oil- 



BUILD_DESNAM_TABLE: PROCEDURE (gESHAM_SIZE) ; 

i ?.3 h 



74 1 

75 2 DECLARE DESNAM_SIZE DWORD; 
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76 a-^^a^-* DECtSfB'E DE3NAH_0SED DWOfeD, 

i'^ ' 'DESNAM HEADER STR0C¥0RB 



SRI 



77 2 DESNAK'^^*'; 

/* AH'ob¥t#^a segment for the table */ 

78 2 CALL ALLOCATE (DESNAM_SEL, DATA_W, 

l3ES'NAM_WrbTH * ( MODULE_HEADER . DESCR COUNT + 1), @EXCE 
-P) ; 

79 2 IF EXCEPTION THEN CALL REPORT (?EXCEP) r' ' ' ' 

/* Initialize the table */ 

81 2 DO DIX=0 TO MODULE_HEADER. DESCR_COUNT; • 

82 3 CALL MOVB(@(' ' ) ,§DESNAM (DI X) . NAME (0 ) , 1 ) ; ' 

83 3 CAtfbi'HOVB.(eDESNAM(DIX) .NAME(0) , '''■<■ 

@DESNAM(DIX) .NAME(l) ,DESNAM_WIDTH-1) ; 

84 3 END; 

/* Read each descriptor name */ 

85 2 DO WHILE DESNAM_USED < DES NAM_S I ZE ; 

/* Read fixed portion of DESNAM record */ 

86 3 ACTUAL=DQ$READ (LOAD_FILE, @DESNAM HEADER, 3, @EXCEP) 

87 3 IF EXCEPTION THEN CALL REPORT (l?E!^^P"i7 

89 3 DESNAM_USED=DESNAM_USED+ACTUAL,- ' ' , 

90 3 DIX=DESNAM_HEADER.DESCR_IN-1; ■ ' fil 

91 ■ ' '3 DESNAM(DIX) .NAME (0 ) =DESNAM_HEADER . NAME_LENGTH; 

• ■ ■ /*' Read rest of name into table entry */ ^ 
9.2 3 ACTOAL=DQSREAD(LOAD_FILE,iaDESNAM (DIX) .NAME (1 ) , ^^-J 

DESNAM{DIX) .NAME(0) , @EXCEP) f 
93 3 IF EXCEPTION THEN CALL REPORT (^EXGEj).; 

95 ■ 3^ DESNAM_USED=DESNAM_USED+ACTUAL; ^' ' - ■ '- 

96 3 ^ END /* iJO LOOP */; ' il 

97 2 END BUILD_DESNAM_TABLE; 

^*******************************************************^ 

58;:9S',^:3B , ja^LOAD' SifeKBStsr *feofcte»jtlIffi-(tolDlTXT ¥t2E)? ' ■ " - ^ ' 

99 2 DECLASt LODTXf_;ffIZE DWORD; ^ 

100 2 DECLARE LODTXT_HEADER STRUCTURE-' f ' - * 

« LOAD_OFFSET WORD, iq«-'a *\ CK2 \i: 
DESCR_IN WORD, 

LENGTH WORD '--J','' O.m . bZ ! 

COUNT WORD, 

"'•*****'"*■ ■ LODTxT Wed '■ DWORD; ""''^ 

101 2 DECLARE NEW_LDT_SEL SELECTOR, 

n^- : ,-.3 NEW_LDT_SEL_W WORD AT (?NEW_LDT_SEL) , 

SEG_RIGHTS BYTE; - 

102 2 DECLARE TSS_IN LITERALLY ' 0FFFDH ' ; " •' ' " 

103 2 LODTJC^-OSBDisaf;' 

/* Step thru all LOOT XI: record* «/ 

104 2 DO 'WHILE LODTXT_USED<L'Oid*XTj^gWii?}-' ' 
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105 
106 
108 
109 

110 
111 

112 
114 
115 

116 
117 
118 

119 
120 

121 

122 

124 



125 
127- 

128 
129 



131 

132 
133 

135 
136 
137 

138 



139 

140 
141 
143 
144 



/* Read in the LODTXT header */ 
3 ACT0aL=DQ$READ(LOAD_FILE,eLODTXTJlBI^Jt^eEXCEP)3 

3 IF EXCEPTION THEN CALL REPORT (QIxCEP) ; 

3 LODTXT OSED»LO0?;^4.USED-li|ip'^J^, 

3 IP LODfXT_HEAE^W#Sqji^f^^Jp 

3 THEN DO; /* Load the Task State Segment */ 

4 ACTUAL=DQ$READ (LOAD_FILE,@TSS , LODTXT_HEADER. LENGTH, 

gEXCEP); r, 
4 , IF EXCEPTION THEN CALL REPORT (eEXCBt')?' 

LODTXT_USED=LODTXT_OSED+ACTUAL; 
END /A. ,l«iad In^ -jCftSk" Stsate Segment */; _ p- 

ELSE DO; /* Load a data or code segment */ £ 
LIX=L0DTXT_HEADER.DESCR_IN-1; 
IF (SEGDT (LIX) .RIGHTS AMD 0«H) = 06H ;,o 
/* expand-down data segment? */ 
THEN SEG_RIGHTS=DATA_WD; , . i ■ .[ ; 

ELSE SEG_RIGHTS=DATA_W; t-r '. / . " 

/* Allocate a segment */ . v 

CALL ALLOCATE (DCS_SEL, SEG_RIGHTS, 

SEGDT (LIX) .LIMIT+1, @EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (8EXCEP) ; 
' /*' Read LODTXT record into segment */ 
ACTOAL=DQ$READ (LOADFILE, 

. ■ B0ILD5PTR (DCS_SEL, LODTXT_HEADER. LOAD_OFFSET) , 
L0DTXT_HEADER. LENGTH, @EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (@EjCCBP^/; r 
L0DTXT_USED=L0DTXT_USED+ACTUAL; 

actual access rights in descriptor */ 
fcALL 'ShaNGE_AR (DCS SEL, SEGDT (LIX) .RIGHTS, §EXCEP) f 
IF EXCEPTION THEN CALL RBSOST (QEXCEP) ; ,, 
/* Construct selector for slot in hew LOT */ 
/* DPL = 3; TI = 1 */ r- 
NEW_LDT_SEL_W = (SHL(LIX,3) OR 07H); 

/* Transfer descriptor to new LDT */ 
CALL LOAD L0T (T^SK:^SLPT,t!EW I,aT SEL.DCS SEL,eEXCBP)^f,^ 
IF EXCEPTTon then cAtL REPORT (TeIXCEP) ;~ 
/* Mark descriptor as allocated */ o 
4 SEGDT (LIX) .RIGHTS=ALL0CATED; 

4 END /* loading a data or code segment */; \ s ; 

3 END /* stepping thru all LODTXT records »/; 

2 END LOAD_S.BGHENTS ; 

/*»*»****»**»**» If p^^ff^^ii*ii^^»jlfii,i^»t^ii^***»» / 

1 LOADDESCRP: PROCEDURE; 

.r.:2 J ^ 

/* Allocate a segment for the DESCRP section */ 

2 CALL ALLOCATE (DESCRP_SEL, DATA_W, 

8*M0DULE_HEADER.DESCR_C00NT, gEXCEF) ; 
2 IF EXCEPTION THEN CALL REPORT (esXCEP) J . .. 

/* Step thru all descriptors */ 

2 DO LIX = TO MODOLE_HEADER.DBSCR_CO0|MT~!lj) ■ ^■ 

/* Read- tiWl en.tiy */ , 

3 ACTDAL'bQ^WB^D ...(LQAD^ILE, @ SEGDT (L^]^>.<, - ^ 

^ 8, SEXCEP) ; 
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IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 

/* Is it marked with Present bit ^-.jl,,,? */ , 
IF (SEGDT (LIX) .RIGHTS AND 80H)=a "THEJNf ' 
- /* Is it a call gate? */ 

IF (SEGDT (LIX) .RIGHTS AND 0FH)=4 /* Type field */ 
THEN DO; /* Insert pointer from BOND table */ 
CALL FIND_BOND (@DESNAM (LI X) .NAME, 

@GATET(LIX) .ENTRY_POINT, @GATET(LIX) .SEL, 
' @EXCEP) ; 

IF EXCEP=OK THEN /* Set present bit. */ 

GATET(LIX) .RIGHTS=GATET(LIX) .RIGHTS OR 80H; 
END /* inserting pointer */; 
END /* stepping through all descriptors */; 

END LOADDESCRP; 

^* ****************************************************** ^ 

/* Transfer remaining descriptors t(3 rjew LOT */ 

TRANSFER_REMAINDERS: PROCEDURE; 
/* Handles descriptors for which there was no 

ftODTXT record (e.g. stacks and gates). */ 

DECLARE NEW_LDT_SEL SELECTOR, ' 
' NEW_LDT_SEL_W WORD AT (@NEW_LDT_SEL) , 
SEG_R1GHTS BYTE; 

/* Step thru DESCRP entries, skipping LOT alias */ . 
DO LIX = 2 TO .M0DULE_HEADER.DESCR_C0UNT-1; '' ' 

IF (SEGDT (LIX) .RIGHTS AND 0FH) = 4 ! ' 

THEN /* call-gate */ DO; , 
/* Construct selector for slot in new LDT */ 
NEW_LDT_SEL_W = (SHL(LIX,3) OR 07H); 

/* Transfer descriptor to new LDT */ 
CALL LOAD_LDT_GATE (TASK_SLOT, NEW_LDT_SEL, 

GATET(LIX) .RIGHTS, ' ^ " 

BUILDSPTR(GATET(LIX) .SEL, , 

GATET (LIX) .ENTRy_POINT) , '' 
GATET (LIX) .WORD_COUNT, @EXCEP); ^ . ^ 

IF EXCEPTION THEN CALL REPORT (@EXCEP) ; ' 
END /* call gate */; 

ELSE IF (SEGDT (LIX) .RIGHTS AND 10H) <> ^ 
THEN /* unallocated data or code segment */ DO; 
IF (SEGDT (LIX) .RIGHTS AND 05H) r. CfiH 
/* expand-down data segment?^*/" ' 
THEN SEG_RIGHTS=DATA_WD; , , . 

ELSE SEG_RIGHTS=DATA_W; y, 
/* Allocate a segment */ ' ''_ 

CALL ALLOCATE (DCS_SEL, SECJiJtiKTJ^, . 

SEGDT (LIX) .LIMIT+1, eEXCEP)'; " 
IF EXCEPTION THEN CALL REPORT (OEXCEP); 

/* Put actual access rights in descriptor */ 
CALL CHANGE_AR (DCS_SEL, SEGDT (LI X ) . R I GHTS , @EXCEP); 
IF EXCEPTION THEN CALL REPORT (?EXCEP); 
/* Construct selector for slot in new LDT */ 
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PL/M-M^ COMPILER 96B'-%i5 ^k'tlfe"'' • ' ' t«lfdl^ 'ff 

/* DPL = 3; TI = 1 */ ■' ^' 

177 4 NEW_LDT_SEL_W = (SHL(LIX,3) OR 07H); ■, 

/* Transfer descriptor to new LDT */ 

178 4 CALL LOAD_LDT (TASK_SLOT,NEW_LDT_SEL,DCS_SEL,@EXCEP) ; 

179 i ' IF EXCEPTION THEN CALL REPORT (SEXCEP); 

181 4 ^ END /* unallocated data or code segment */; 

182 3 E^bV* see^pin^ ^flra'-iifiSCRP entries */; 

183 2 E^D TRANS FER_REMAINDERS; * 

/*' sioiTf, .a=.t. Line ""' *N ^ "*/ 

184 1 CALL INITIALIZE_SYSTEM; wA.'J 0/3 

185 1 CALL BUILD_BOND_TABLE ( @BOND_F I LES PEC , @EXCEP) ; 

186 1 IF EXCEPTION THEN CALL REPORT (SEXCEP); 

188 1 CALL RESERVE_SLOTS (IN_LDT, 1, (aDCS_SEL.,. ^^EXCEP) J , -...^ 

189 1 IF EXCEPTION THEN CALL REPORT (laEXCEP); ',' ' 

191 1. . CfttL^gESERyE_SLOTS (IN_LDT, 1, iaDESCRP_SEI., SEXCEP); 

192 1' IF EXCE^TlOM THEN CALL REPORT (@EXCEP) ; 

194 1 CALL RESERVE_SLOTS (IN_LDT, 1, @DESN4M,SEI.., @EXCEe) ; 

195 1 IF EXCEPTION THEN CALL REPORT (gEXCfipf? 

197 1 DO FOREVER; > ■.'"HO 1 5i Oi! c 

198. ■'2'''^" GET NAME: 

CALL GET_LOAD_FILE (@PATH_NAME) ; /* May wait */ ^ 

199 2 LOAD_FILE=DQ$ATTACH (@PATH_NAME, @EXCEP) ; 

200 2 IF EXCEPTION THEN GOTO GET_NAME; ' ' 

202 2 . , CALL DQSOPEN (LOAD_FILE, READ, 1, @EXCEP) ; 

203 2 IF 'EXfeEPTION THEN CALL REPORT (?EXCEP)';, 

/* Read file header. */ 

205 2 ACTOAL=DQSREAD (LOAD_FILE, @FILE_HEADER, 1, 8EXCEP) ; 

206 2 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; " 

/* Read loadable-module. l)e|«3er */ 

208 2 »CTUAL=DQSREAD (LOAD_FILt, 'SMObdLE_HEADER, 

. . ., ^ , S.IZE(J«l6Dpi;,E HEAOEJR) , SEXCEP); 

209 2 IF .feifciPTION' THEN CAtI,' RttORt" (@EXCEP) ; 

/* Process DESNA.^1 section of OMF */ 

211 2 CALL DQ$SEEK (LOAD_FILE , 2 , MODULE_HEADER . DES NAM_LOC , 

- , , - , @EXCEP) ; F ! . 

212 2 IlP EXCEPTION THEN CALL REPORT (SEXCEP); 

214 2 CALL BUILD_DESNAM_TABLE (SECTION_S IZE (3 ) ) ; 

/* Tell OS to allocate an LOT */ ^ ., .' 

215 2 CALL RESERVE_SLOTS (IN_GDT, 4, @TASK_SLOT, SEXCEP) ; 

216 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 

218 2 CALL CREATE_LDT (TASK_SLOT, MODOLE_HEADER.DBSCR CTONT, 

SEXCEP); 

219 2\. 5 IF EXCEPTION THEN CALL REPORT (SEXCEP); 
■ ' . '^:<"jft , 

/* Process DESCRP section */ 
221 2 . „ , eiitt petS.EEK (LOAD FILE, 2',Mb£)tJt^'i£fe^nfeR. DESCR* I.ofe, 
- ^ - SEXCEP); - 
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p]E./M-:^.f,, COMPILER sffsgis :saaitte sajiqMo.' p*ge-: -» 

222 2 IF EXCBeT;IOJN\3!MBN CALX ITEPORT (JgEXGEP) J 7 Cl?-m>J- v 

224 2 CALL LOAD_DESCRP; ;; i. :. JJU?nr t-i^aL 

/* Process LODTXT section */ 

225 2 CALL DQ$SEEK (LOAD_FILE , 2 , MOD0LE_HEADER. LODTXT_LOC, 

@EXCEP) ; 

226 2 IF EXCEPTION' T-HEN'©ALL:» JfEfDSffXTOSfiSfiCBiflJE^Aq 

228 2 CALL LOAD_SEGMENT#^tSKDSlI«aiOISaKEi(t ) ■J')-'!''^'' ' 

229 2 CALL TRANSFER_REMMBOraiS*nn;3 : I ■? : 1 

/* Tell OS to create the new task */ 

230 2 CALL CREATE_TASK(TASK_SLOT, @TSS, DEFAULT_PRIORITY, 

9EXCEP) ; - 

231 2 IF EXCEPTION THEN CALL REPORT (?EXCEP) ; 

233 2 CALL DQSCLOSE (LOAD_FILE, @EXCEP); 

234 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 

236 2 CALL DQSDETACH (LOAD_FILE, @EXCEP) ; : 

237 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 

239 2 CALL FRBE_SEG (DESCRP SEL, (SEXCEP) ; 

240 2 IF EXCEPTION THEN CALL REPORT (dEXCEP); 

242 2 CALL FREE_SEG (DESNAM_SEL, @EXCEP); 

243 2 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 

245 2 END /* FOREVER */; 

: , a: . - ^ ; ' 

246i>iT4_q3:->^ E.ND LO^i^; T;r.00 .QfiOW j.iSAT .^V : :: 

-, :-TOJ? avftaaa<! ov.:^ 

MODOLB ,i|pppftfION: : 

CODE AREA SIZE. = 0'8B2H 22260^ i . v. ,...it>, ■ 

CONSTANT AREA SIZE = 0001H . : 10 .Svia ' - i 

VARIABLE AREA SI?5E;i>-= 0,afWl , ^ ,2J%5D)-';-. ,.Tq -■ t ) 

MAXIMUM STACK SIZE = 9018H' -TMSl ■ : a-: -\ '.■'D 
508 LINES READ 

PRQGRftM WABtHOKSS? f.THM: , 2> J -iiWa" - ; ? 

PROGRAM ERRORS 

DICTIOHART SUMMARY: ■-. - v . 

96KB MEMORY AVAILABLE ' 
11KB MEMORY USED ,(11%) , ■ , , lit 

BICS ,0ISK SPACE USED ;SS'n;.i09 HT«I 'i 4 f i 



END m PL/(t-286 COMPILATION 
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PI,/»SW8 COMPILER 9««*S21 ■? -l '''^ pti^ i"' 


system-ID PL/M-286 Vx.y COMPILATION OF MODULE BOND ! 

OBJECT MODULE PLACED IN :F1:B0ND.0BJ . - -'J i-- 

COHfSIM INVOKED BY: PLM286 . 86 ;F1:B0ND.PLM DEBUG 






$ PAGBWIBmC?!,) :TITOEX'.'96a»S21'.|''''"'^3''>^^' •• • 
$ INCLODEf i{5Sf'.la;M:^S!OTa.W*B"'''''^-'l^ ri/!OJ JJ^'J JtSf 
* 9 NOLIST 

$ INCLUDE (sFl:UDI|PmiCi*»t3f:a.^ ■I'-^-i'/AiiT .MAO "ii 
$ NOLIST 

$ COMPftC&^sJ vs.; ■'x 


1 




BOND: DO; 

/* Language Extensions - '• ' */ 

. i ■; t ■ 


2 


1 


DECLARE BOOLEAN LITERALLY '-S^E:*'-;.- - - 

; (' ^ALSE LITERALLY ' g'-'," " ' ' " ' i 
TRUE LITERALLY '0FFH', 
TOKEN LITERALLY 'WORD', 
CONNECTION LITERALLY 'TOKEN', 
OFFSET LITERALLY 'WORD'; 

*********************************** ************** / 

/* Extetri'alB' '"^ ' ''' / 


i 

5 


l' 

2 

2 


*" RESERVE SLOTSr ?ROiC*tfC»(TR»y,C© PTR, EXCEP PTR) 
EXTERNAL; ~ 

DECLARE TABLE WORD, COUNT WORD, ;fSK|i0.4><J<#:,i EXCEP t'TR)- 
PO INTER ; 

END RBSERVE_SI.0TS ; 


4. 

7 
8 


1 

2 
2 


GET_GATE POINTER: PROCEDURE (GATE SEL, S^G SEt PTR, ' 
SEG_OFFSET_PTR, EXCEP_PTR) EXTERNAL; 
/'"' Returns selector and offset from a gate descriptor */ 
DECLARE GATE_SEL SELECTOR, 

(SEG SEL PTR, SEG OFFSET PTR, EXCEP PTR) POINTER; 
END GiET_GftTE_^POIN^W; "Rf* Wf. - '.o 


9 

10 
11 


1 

2 
2 


ALLOCATE : PROCEDURE (SLOT , RI GHTS , St=8*,iiSai«' >S<I*) i ^ 
E XT ER N A L ; "P.O -iil ? T. M S H 
DECLARE SLOT SELECTOR, RIGHTS BtTE, SIZE WORD, 
EXCEP PTR POINTER; ; Yvi • '; j s a ■■voir I: 

END ALLOCATE; 


12 
13 
14 


1 
2 
2 


REPORT: PROCEDURE (EXCEP PTR) EXTERNAL; ■ ' 
DECLARE EXCEP PTR POINTER; ' ' 'CIO 'i^i> 
END REPORT; 


IS 

16 
17 


1 

2 
2 


DQ$ftTTACH: 

PROCEDURE (PATH$P, EXCEP$P) CONNECTION EXTERNAL; 
DECLARE (PATH$P, EXCEPSP) POINTER; 
END DQSATTACH; 


18 


1 


DQSDETACH: PROCEDURE (CONN, EXCEP?1>) E»gSNaL; 
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Pt./M-t8* I COMPILER 9i«»621 saj fqMr':jPAGE-:'\2^- 



19 2 DECLARE CONN CONNBSflON, E«^fO POINTER; 

20 2 END DQ9DETACH; 

21 1 DQ$OPEN: ' 

PROCEDURE (CONN, ACCESS, NUM$BUS»' ;*EXCEP$P) EXTERNAI,; 

22 2 DECLARE CONN CONNECTION/,.! (aGCESS, NOMSBOF) BYTE, 

EXCEPJ^P PO INTER{i Y-lJUi rt; Jl 

23 2 END DQ$OPEN^n.' .las TOO 

24 1 DQSSEEK: PROCEDURE 

(CONN, MODE, LOCATION, EXCEP$P) EXTERNAL; I 

25 2 DECLARE CONN cCONNECTIOIftMlMI^S 

location- dword, excbft$p--po inter; 

26 2 end dq$seek; 

27 1 dqSread: procedure 

(conn, buf$p, count, excep$p) word external; 

28 2 declare conn connection, count word, 

(mB$<Bir.-,'msmp$B). pointer; «■.. 

29 2 END DQ$READ; 

30 1 DQ$CLOSE: PROCEDURE (CONN, EXCEP$P) EXTERNAL; 

31 2 DECLARE CONN CONNECTION, EXCEPSP POINTER; 

32 - ' 'i2 jso/'i' .END!_0ffiii3ffi.«B* : :i>wazxp.f :3ja.'i- ; 

^Itrk * #^ t'* * ^4;,* *******,**.*********** * 4^*,*^.*,* ****** *A ***** 

/* -J V Data */ 

33 1 DECLARE IN_LDT LITERALLY '1', 

DATA_w LITERALLY '11110010B', /* Access rights: 
present, DPL=3, expand-up, writable, data segment */ 

READ LITERALLY ' 1 ' , ' ,. 
i>:>i:«@8ALS:-' LITERALLY '.0KFFFH' , ; 
OK LITERALLY '0' , 

• EXCEPTION LITERALLY ' EXCEPOOKfif / H : 

34 1 DECLARE BOND_FILE CONNECTION, 

ACTUAL WORD, 
] ir SEL SELECTOR, /* for type conversion */ 

'i:".'lSBL T'/.. WORD AT (@SEL); -j i 

35 1 . I--' r-BBCLARE FILE_HEADER SXTI;- , ■ ■ : , . -AO 

• . , I ■ . ,. . -- -, . ■ 

36 1 DECLARE MODULE_HEADER STRUCTURE ( \ 'i 
; («iaOXa§, I. 1 ■ • TOTAL_LENGTH DWORD, 

SEGMENT_COUNT WORD, ::P 

GATE_COUNT WORD, 

PUB_COUNT WORD, \ 

: horn It. 1 • - :i f*XT_CaONT ^ , WORflj , «x 

J L-INKED - ^, BYTE., 

. : JO__lliOa': . DATE (8) BYTE, 

TIME (8) BYTE, 

MODULE_NAME (41) BYTE, 

- CREATOR (41) BYTE, 

IGNOREl (6) DWORD, 

\ . -JspBiJEFLOC , CMORD, 

;(<3S':>:. ,;■ , »B©EI'r):.,ENpTH-,- > w ■-; ,r PWORR, ^ j.. 



f.^ui<e llTZi^ JBlOliD Module efJiiiisUii9iUQader,(CQnt'|t<) 

H-2S 
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■•'■:oaQB©«E2X2 .HOlTCBIJt!;-. DWORD); S Pi 






_ S '. ^ 

/* Table of actual locations of O.S. primitives */ 


37 


I 


DECLARE BOND SEL SELECTOR, 






.-i -n'DX BOtHS BASED BOlffi :SEL. ■■<(«:)■■ STWU05E0KB!-rI( 






i^.!::;/ 5';GATEHAME^(41) BYTE, s 






ENTRY POINT 0PPSE'!lS><5J 0X3 






GDT SEL SELECTOR; ) , r 






BIX WORD; /* Index */ 

t ■ l>i 


38 


1 


DECLARE PUBDEF STRUCTURE . j ■. 






tENTRlf P®tM'5H':'i . .= .«ORDr i" ■ riM^JIjO S ?i 






; GOT IN 'X' .r.qo ■ WORD, , ' ' 






IGNORE WORD, - ' £ ~" 






WORD COUNT arPE, 






LENGTH BYTE); 












y^n***** ************************************************ ^ 






/* ,J? k>..'! (?es5BJI^outines */ 






/* Create table of actual GDT selectors and 






entry poifttis ,f6'E:o. ft. 'p*iinlfeive«i- C I ■ 








39 


1 


BUILD BOND TABLE: PROCEDURE <B0!fWJ8»lSB mU, EXCEP •'.PTR): ' 






PUBLIC ; 


40 


2 


DECLARE {BOND NAME PTR, EXCEP PTR) POINTER; 


41 


2 


DECLARE EXCEP BASED EXCEP_PTR WORD; 






/* Initialize filS */' i - 


42 


2 


«OND FILE=DQ$ATTACH (BOND NAME PTR,?EXCEP); 


43 


2 


ftF EXCEPTION THEN RETURN; 


45 


2 


CALL DQSOPEN (BOND_FILE, READ, 1, @EXCEP); 


46 


2 


IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 






/* Read file header */ 


48 


2 


ACTDAL-OQ$READ <BOHD FILE^SFILE HEADER, 1 rSEXCEP) ; 


49 


2 


IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 






/* Read module header */ i. 


51 


2 


ACTOAL=DQ$READ (BOND FILE,@MODULE HEADER, 






SIZE(MODULE HEADER), esXCEP) ; 


52 


2 


IF EXCEPTION THEN CALL REPORT 488XCEP) ; 






/* Get space for table */ 


54 


2 


CALL RESERVE SLOTS XiN EDS'^lijlSBONQ Se^jSEKCEP) ; ' 


55 


2 


IF EXCEPTION THEN CALL REPORT (@EX5eP) ; 


57 


2 


CALL ALLOCATE (BOND SE&, ■ DATA W, ^ Ji! 






(MODULE HEADER. PUB COONT+l ) *S I ZE ( BOND (0 ) ) ,§EXCEP) ; 


58 


2 


IF EXCEPTION THEN CALL REPORT (@EXCEP); 






/* Read the PUBDEF section */ 






/* (Locations are relative to beginning of module, 






not beginning of file. Asfeiime module at 1.) */ 


60 


2 


CALL DQSSEEK (BOND FILE , 2 , MODULE HEADER . PUBDEF LOC+1, 






esXCEP) ; 


61 


2 


IF EXCEPTION THEN CALL REPORT (@EXCEP); 






/* Loop thru the PUBDEF entries */ 


63 


2 


DO BIX = TO MODULE HEADER. PUB COUNT-1; 






/* Read fixed part of PUBDEF record */ 


64 


3 


ACTUAL=DQ$READ (BOND FILE, gPUBDEF, 8, @EXCEP) ; 
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PL/M-286 COMPILER 960-521 date PAGE 4 

IF EXCEPTION THEN CALL REPORT (eEXCEP) ; ■'■'.'^J 
/* Convert index; ^to GOE aelectofc <*/ '"■ 
WSEL=SHL(PDBDEP.GDT'_IN,3) J ' ■ 
/* Extract gate selector and offset from GDT */ 
CALL GET_GATE_PO INTER (SEL, ? BOND ( BI X) , GDT_SEL , 

@BOND(BIX) .ENTRY_POINT, ?EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Read var iable- length name */ \ 
BOND (BIX) .GATE_NAME(0)=PUBDEF. LENGTH; 
ACTOAL=DQ9READ (BOND_F I LE , eBONDitBMO i.CATBrNAMI! (1) : 

IF EXCEPTION THEN CALL REPORT (SSaSBB^SA'i 2 »?,:c. J 

END /* looping thEu POBDEF eniMi^'*'/^''^^ -SS-M - : 

END BUILD_BOND_TABLE; 

FIND_BOND: PROCEDURE (SNAME_PTR, ENTRY_PTR, SEL_PTR, 
EXlSSPJPTR) POBLICf 

/* Search BOND table for given narae. 

Return items from found entry. */ 



65 


3 


67 


3 


68 


3 


69 


3 


71 


3 


72 


3 


73 


3 


75 


3 


76 


2 


77 


1 


7fi 


7 


79 


2 


80 


2 


81 


3 


82 


3 


83 


3 


84 


4 


85 


4 


86 


4 


87 


4 


88 


4 


89 


3 


90 


2 


91 


2 


92 


2 


9S 


1 



.„ . DECLARE (SNAME_J".TB^.EN3aX_ETJU aEi^PJTR, EXCJEE-EIBJ 

I j. POINTER; 

■" ' DECtotf'SNAME BASED SNAME_PTR (41) BYTe', 

ENTRY_POINT BASED ENTRY_PTR WORD, 
GDT_SEL BASED SEL_PTR SELECTOR, 

EXCEP BASED EXCEP_PTR WORD; 

DO BIX = TO MODULE_HEADER. PUB_C00NT-1; 
IF SNAME(0)=BOND(BIX) .GATE_NAME(0) /* Same length? */ 
THEN /* Compare characters */ 
IF EQUALS =CMPB(@SNAME(1) ,@BOND(BIX) . GATE_NAME (1 ) , 
SNAME (0 ) ) 

THEN DO; 

ENTRY_POINT=BOND (BIX) .ENTHY_POHIT; 
GDT_SEL=BOND(BIX) .GDT_SEL; 
EXCEP=OK; 
RETURN; 
END; 

END; 

EXCEP=NOT OK; 
RETURN; 

END FIND_BOND; 

ft*********************************************/ 

END BOND; 



MODDLE INFORMATION: 



Figure 1 1'7. BMD Module of BIndins Loader (Cont'd.) 
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iSu-siV flS-iV".: ./.J •'. . J . 

CODE AREA SIZE = 02CBH 715D 

CONSTANT AREA SIZE = 0000H 0D 
VARIABLE AREA SIZE = 00C2H 194D 

MAXIMUM STACK SIZE = BBlCHi - i . 2BB' . i r . -'j iHg- iSiW £ U 

245-. LINES BEKD ' ' '--fs. 'e-f'-^ *\ 

PRQS^M mBNINGS ■■ I ^0 

S PROGRAM ERRORS 

: . ' ■ t ' 

DICTIOHiRRy SUMMARY: 

96KB. MBBORy.l available: , I-! T ^ nuM ra.'-.3KiOU--.--'.UT E 

8 KB MSMOR T S MD ' : '( 8 % ) ' ' ' 

0KB DISK SPACE USED H r 

END OP K,/M-286 COMPILATION , 



Figure 11-7. BOND Module of Binding Loa(|er (Cont'd.) 

.,1; i ' ^ - ■ . ■ :;3 

( f-Ti" ' ■' r .'. S|i rij '.'ior'' -■- 'jci S'i 

;J'Ho TOO. ( Jia)cH!-: 4 



■ 11 .iui.' 



roc-f »«! ' I 
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121960-001 



Numerics Processor Extension ^ 2 



t. Wrfiir a !fi w -t 



CHAPTER 12 
NUMERICS PROCESSOR EXTENSION 

The iAPX 286/20 is a configuration of chips consisting of an 80286 CPU and an 80287 Numerics 
Processor Extension (NPX). With these two cooperating processors it is possible to construct powerful 
numerics processing systems, but the operating system must multiplex the 80287 among the tasks that 
use it. If the system does not include an 80287, you may choose to have the operating system emulate 
its functions. 



iAPX 286/20 NUMERICS PROCESSING FEATURES 

Several features of the iAPX ;^g6/20 ^e of special interest to operating-system designers and program- 
mers. You can find more details on how to use the iAFX 286/20 in the iAFX 286 Prpgrammer'^ 
Reference Manual. 



ESCAPE Instructions 

The 80287 NPX extends the instruction set of the iAPX 286 by over fifty opcodes. The CPU identifies 
thp extended instruction set by the bit pattern 1 1011 B in the high-order five bits of the first byte of 
tl^ ftstmctioii. Instructions thus mafked are callssLESCAPE of ESC instructions; 

The CPU performs some functions upon encountering an ESC instruction, before sending th^ instruc- 
tion to the NPX. Those functions that are of interest to the operating system include 

• Jesting the emulation mode (EM) flag to determine whether NPX functions are being emulated by 
^^Slware. . ■ ; - ..sq •■ lOTianfj 

•''''i'feting the TS flag to d^ftiiilfe 'tvhitHef thcrti Ifcak been a ^lltext change siiice thfe'j^t'ESC 
instruction. • " - ' ' 

• For some ESC testnictions, testing the ERROR pin to determine whether an error conditiiHi exists 
at the NPX as a n^ult of a previous ESC instruction. 

The ASM280 AssenMv Lamuage Referertee Mmml provides more information on each 80287 
instruction. '^j-'-i-y . .j.' : .. , , 

Emulation Mode Flag (EM) 

The EM bit of the 80286 machine status word (MSW) indicates to the CPU whether NPX functions 
are to be emulated. If the processor finds EM set when executing an ESC instruction, it causes trap 7, 
giving the exception handler an opportunity to emulate the functions of an 80287. The EM flag can be 
changed with the aid of LMSW (load machine status word) instruction (legal only at privilege level 
(PL 0)) and tested with the aid of the SMSW (store machine status word). The built-in variable 
MACHINESIEEAftJl gives PL /M-286 programs access to the MSW. 

The EM bit also controls the function of the WAIT instructi on. If the processor finds EM set while 
executi^ a WAIT, the processor do« not check the ERROR pin for an error indication. 

NotethatEMmustneverbg'iSrteoilemimtlyitdltMP^L- y.: OH 
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The MP bit of the 80286 machine status word (MSW) indicates to the CPU whether an 80287 NPX 
is actually attached. The MP flag controls the function of the WAIT instruction. If, when executing a 
WAIT instruction, the CPU finds MP set, then it tests TS; it does not otherwise test TS during a 
WAIT instruction. If it finds TS set under these conditions, the CPU causes trap 7. 

NotC'tfat MPanust never b&set Goacwrently with EMo ' '-1 ■ -v/- :j i,^ - ui 'i 

^rioi ■ ii.'i -ti 

Task Switchtcl Flag (TS) 

The TS bit of the MSW helps to detehnine when the context of the 80287 NPX does not match that 
of the 80286 CPU. The CPU sets TS each time it performs a task switch (whether triggered by software 
dfby hardware interrupt). If, when interpreting one of theESCiliStnictfeaS,'tite®PS'fijads'ra al^edajr 
set, it causes trap 7. The MP flag also relates to TS. • • ^ 'om bail nc, ■ .,v:'v. 

The CLTS instruction (legal only at PL 0) resets TS. 



WAIT Instruction 

The WAIT instruction is mt »p E§p Jfls^rvptj58i,^^t >^ 

same tests that it performs upon encountering an ESC instruction: 



The CPU waits until the NPX no longer asserts the BUSY pin. You can therefore use WAIT to 
synchronize the CPU with the NPX. 



■; The- CPU tests the ERROR pin (if EM is Ti©t wt); ¥oii can therefore use WAIT to cause trap 16 
if an error is pending from a previous ESC instructi on. (The C PU makes this test only after BliSY 

- j,.goes inactive.) Note that, if no 80287 is pt^v^^ J^^^^^^fj^f^ ^WStive to prevent 

WAIT from causing spurious traps. 

Summary ~.=i;.ii;j.P, 'M:, .„o,v.v, h n.<, ^ in 

Table 12-1 summarizes functions of the ESC and WAIT instructions that depend on setting of thp MP 
and EM flags. 



INITIALIZATION 

During its initialization phase the operating system must 

• Set flags in the MSW tp>rfcfle0ttiie.nutiieries'processii^;eiivii!0iMBel*t-' 'i '■ to bi^ sii ' .< i 
•'' ■RMetthe80287 (if prwentj' -'^^^^ '^ . 

• Switch the 80287 into protected mode 

You can use a configuration parameter to communicate the numerics processing environment to the 
operating system. The FNINIT instruction (INIT$REAL$MATH$UNIT in PL/M-286) resets the 
80287, and the FSETPM instruction places the4l02S7'4B|ffl.frci!B!Si6d mm^ --r ^ i. ;: j lu.y 
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Table 12*1. lftfe»rpr«tallofii0f MP and EM Flags 





EM Flag 


Set 


Reset 


MP Flag 


Reset 


Set 


WAIT 


TRAP 7? 

TEST BUSY? 

TEST ERROR? 
(TRAP 16) 


N 
Y 

.'.u'/..ii1||!?"j i : 


if TS = 1 
Y 




TRAP 7? 


Y 


If TS = 1 


ESCAPE 


TEST BUSY? 


N 


Y 




TEST ERROR? 


N 


Y 


: - . ..i J!lIiJ : 


(TRAPt^ 








i-iDii 0'''i'ii ' ii 1' in 




ir'l lie if »lU 'Hi.-llll. u 



, . It;:. „ - ■ : 2 r I ' rut: .■ 

TASK STATE ./i/ -n.'; ^.-a' ■■ ,\ in-- ir., ii-,/ 

W^en ia task uses i^i? l^X, the operating system has two additional concerns in kee^piajg, track 
of the task's state: 

« Jllie task.datab^|^iiii§trbe eKpK^yHjftd1nc]fide47 words of state information for the 80287. 'i 
• The operating system must change 80287 state when a different task attetnpts to use thfe 80287. 

The state of the 80287 consists of 47 words. Saving and restoring the 80287 state is therefore a relatively 
expensive operation that should not be performed any more frequently than necessary. Typically, only 
a few of the active tasks in a system use the NPX; therefore, it would be wasteful to save and update 
the state information with every task switch. It is preferable for the operating system to. record whic^ 
task is using the 80187 and to swap state information biify wiieti iome biti^' task attempts to tise the 
80287. 

The 80286 supports sharing of the 80287 by providing the TS flag. The processor automatically sets 
the TS every time a task switch occurs. The first use of an ESC or WAIT instruction when the TS is 
set causes trap 7. This enables the operating system to keep track of the^l^jk, wjjit^ thsi 
assigned at any ^iven^time and to change 80287 state when necessary, .^^i ^j 1. .„ ,. - , , 



NUMERICS EXCEPTIONS 

Three interrupt yeptgr positions are reserved for exceptions that relate to numerics processing. Interr 
ruptsforthese veett9fs afi? noti]^^M& ! i !^ v<; v. 'LOf! - .i t^, j , l li j.i < 

Interrupt 7 — Processor Extension Not Available (NM) 

This exception occurs in either of two conditions: . - 

• The CPU ^eoatgH&istain'E^C instructioii mMl EM is set. In this case, the exception handler should 
emulate the insMction that caused the exception. TS may alsQfbesetd J I ^ ^ y.ii ■ >• 
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• The CPU encounters either the WAIT instruction, of an ESC instruction when both MP and TS are 
j- set. In this case, theiiKraptiomiiaHidter-sli|ni^^^ 

EMULATION 

The return link points to the first byte of the ESC instruction (or to the prefix byte, if any). As the 
emulator decodes the ESC instruction, it should step the return pointer so that, at the end of the 
emulation routine, the return from the exception handler causes execution to resume at the first 
i instruction following the ESC instfuction. i ^RC 

WdATTNG STATE ^ ' 

To make sure that the state of the NPX corresponds to the current task, the operating system should 
implement the concept of "ownership" of the NPX. (jht^^jiip (am be indicated by a Boolean in the 
task database^ (TDB). The operating system must ensure ttet'<t^yitne taskjat a time is marked as the 
lowaer of- t he T he excepticw handler stioald follow-thege-steps- • — J 

1. Use the CLTS instruction to reset TS. 

2. Return if the current task owns the NPX. 

3. Use the FSAVE ESC instruction {PL/M-286 SAVE$REAL$S.JjA,Ty|J,|e store NPX context m 

the former owner's task database. " ' ' ' ' '', . 

; rri; to 

4. Record the current task as the owner of the NPX. 

5. Use the FRSTOR ESC instruction (PL/M-?^6 RESTORiES'llEifUjSSlAffiUSJcto ther^CPJf 
context from the new owner's TDB. . f~ . 

Since task switches may occur during execution of the exception handler, steps 3, 4, and 5 are a critical 
region and must be protected by a mechanism such as a semaphore. 

The exception handler must run at PL 0, both because it alters the critical task database at PL and 
because it uses th^^pnvil^t^^ii^ ■'■,.■.■;-„■,■,,■<, r' 

The exception handler must be an interrupt procedure, not an interrupt task. If it were an interrupt 
task, the task switch that occurs upon returning from the exception handler would set TS, thereby 
causing the exception again. 

fhe lietlirn link points to tne'fttst byte of the interrupted instruction, Return from the exception handler 
causes restart of that instruction, but this titne TS is reset and the ifistructioh can proceed. 



Interrupt 9 — Processor Extension Segment Overrun (MP) 

This exception occurs when a memory operand of an 80287 instruction has a segment-limit violation. 
Since the 80287 e3»cutes in parallel with the 80286, two difficttrtiSfe Hiay arffle: ^ ^'nu • 

• The occurrence of this exception may not relate directly to the instruction stream being executed 
by the current task. A task switch may have occurred since the 80287 began executing the instruc- 
tion. Even if the interrupted task is the correct task, its IP may have been advanced by several 
instructions beyond the ESC instruction. -.-f^ 

• Since the exception is not maskable, it may occur while interrupts are disabled. If minimum inter- 
biijnt^ latesiej' k^iniportaalUthe exeeptkin hmidl^ mMdaas littleas.i»issible. It coold, fbr exam^jle,* 

record the error for later hBiidiing. 'L .;t; ?^ ' : >> < j j ' 'j-. nj^j i.':f1i ■ i) 
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The offending ESC instruction cannot be restarted. The task containing the ESC instruction (which 
may not be £»|*eiit task) must eventually be cancelled. 

The exception handler must execute an FINIT instruction before executing a WAIT or other ESC 
instruction; otherwise, the WAIT or ESC instruction will never finish. FINIT does not affect the CS:IP 
value and data addte^ saved is the 80287. 

Note that the 80286 CPU detects some addressing violations before sending the ESC instruction to 
the 80287 NPX. In these cases, the CPU causes trap 13 (pushing an error code of zero), and it is 
generally possible to restart the ESC instruction. Refer to Chapter 7 for more information regarding 
trap 13. 



Interrupt 1$ — Processor Extension Error (MF) 

The 80287 detects six different exception conditions during instruction execution. If the detected 
exception is not masked by a bit in the control w ord, the 80287 communicates the fact that an error 
occurred t o the CPU by a signal at the ERROR pin. The CPU causes interrupt 16 the next time it 
checks the ERROR pin, which is only at the beginning of a subsequent WAIT or certain ESC instruc- 
tions. If the e xception i s masked, the 80287 handles the exception according to on-board logic; it does 
not assert the ERROR pin in this case. 

The six exception conditions are 

1. INVALID OPERATION 

2. OVERFLOW 

3. ZERO DIVISOR 

4. UNDERflXJW 

5. DENORMALIZED OPERAND 

6. PRECISION (INEXACT RESULT) 

The steps to be taken to remove the error condition depend on the application. 

Once the exe^^n handler corrects the error condition causing the exception, the floating point 
instruction that caused the exception can be restarted, if appropriate. This cannot be accomplished by 
IRET, however, because the trap occurs at the ESC or WAIT instruction following the offending ESC 
instruction. The handler must obtain from the 80287 the address of the offending instruction in the 
task that initiated it, make a copy of it, execute the copy in the context of the crffending task, and then 
return via IRET to the current CPU instruction stream. 

The ESC instructions that do not cause automatic checking of the ERROR pin are FNCLEX, FNINIT, 
FSAVE, FSETPM, FSTCW, FSTENV, and FSTSW. You can use the WAIT instruction to test the 
ERROR pin before these instructions, if necessary. 
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CHAPTER 13 
,pJ(TENPED PROTECTION 

•■'i , J -!.•!€►» ■..i-^cr< ■ - . , i ...... ri-.' '' vd 

Even though the iAPX 286 architecture provides extensive, automatic protection, a fully protectei^ 
system requires additional protection features in the operating system. Operating-system software calf 
increase the reliability of the system by providing any of these protection features: -■! 

. Extendingthe«t^jrkn^""^' ^ "^^"'"^ ' ' ' 

• Validatii^ pointer parameters 

• Defining the right to use operating-system objects .i^^t'. > . -kr . . "^i 

• Defining the right to delete segments |- 

• Protecting shared objects that are being constructed 

EXTENDED TYPE 



It is both convenient and dangerous to use a selector as the name of an operating-system object. The 
danger arises from the fact that the selector by itself carries no information regarding the type of obje^ 
it identifies. A program can, for example, mistakenly pass the selector of a semaphore to an operating 
system procedure that operates on mailboxes, producing catastrophic results. The solution is to associ- 
ate a type ext^ion^code for the oly^ct with the, segment in wW<?h it resides or with a descriptor to 
tilat 'segment. uf>^¥tih'g-systeih pro^^ can iKen check t^ie type dlT objects identified by selectpr. 
parameters. (The term type extension code is used here to avoid confusion with the processor-recogniz^ 
type code in a descriptor.) , 

There are three general methods of associating type with operating-system objects: 

1. Place the type extension code in the segment in which the object reside. 

2. Associate the type code with a descriptor for the segment. 

3. Use indirect names and associate the type code with the name of 'the object. ■ - ■ 

Only segments likely to contain named operating-system objects need to have type extension codes; 
namely, privilege-level (PL 0), expand up, writable, data s^ments. 



Type Ext«!M^iin Code with Descriptor 

A logical way to store a type extension code is to associate it with the descriptor for the named object 
(you can view the itype extension code as a refinement of the processor-recognized type CQCi? in the 
access-rights byte of the descriptor). The type extensjon code_can be put in a table parallel Jp thg. 
descriptor t^^ ^as ipi^trated^ in Copter S in connection wit^ altasr^gointers). 



Type Extension Code In Segment. i 

It is also possible to place the type extension code at some reserved location in the data segment itself. 
This approach does not reference another segment and thereby avoids loading a segment register, — 
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Indirect Naming 

The most general approach to naming avoids giving to less privileged procedures any direct links to 
the named objects. Instead, names are indexes (or perhaps pointers) into a name table, which is admin- 
istered by the operating system at a highly privileged level. Each entry in the name table holds the 
type extension code of the object, the selector of the segment in which the object resides, and any other 
it^ormation needed to ensure appropriate use of the object. This approach not only offers the greatest 
potential for protection, but also makes it possible to change the naming scheme without affecting 
procedures that use the names and provides a consistent way of naming both those objects that reside 
in dedicated segments and those that are packed into a segment with other objects. 



PARAMETER VALIDATION 

There is one type of privilege violation that the iAPX 286 cannot automatically check for. Consider, 
for example, procedure A at PL 3 that passes a pointer parameter via the stack to procedure B at 
PL 1. Procedure A could (accidently or purposely) pass a pointer that refers to a data structure at 
PL 2. Doing so would violate the intent of the protection features of the iAPX 286 because procedure 
A does not have sufficient privilege to operate on the data structure. However, the p/cjcesspr do^s, 
detect the violation because procedure B, which actually addresses the data structure, doesTlliave sum- 
cient privilege to do so. 

The iAPX 286 provides the RPL field in the selector as well as the instructions shown in table 13-1 to 
help software guard against such protection violations. 

In addition to type checking as mentioned previously, an operating system can provide two levels of 
parameter validation: . . ^.u.i..>v,., 

1. Defensive use of ARPL instruction '.^> 

Defensive Use of ARPL 

Simply by applying the ARPL instruction to every pointer parameter it receives, an operating system 
procedure guards against complicity in accessing a segment that the calling procedure has no right to 
&^G§^ ^BffJ^}^»^pm selie(ipt@f fiperands, for example: 

ARPL seLa , seLb 



Table 13-1. Access Checking Instructions 



ASM286 
Mnemonic 

.■I-,, -/^ 


PL/M-286 Built-in^ , 
Function ' 


Description 


ARPL 
VERR 
VERW 
LAP 

LSL 

1 jBngftJfftmiJ-t 


ADJUST$RPL 

SEGMENT$READABLE 

SEGMENT$WRITABLE 

GET$ACCESS$RIGHTS 
GET$SEGMENT$LIMIT 


Adjust requested privilege level 
Verify segment for reading 

Load access rights 
Load segment limit 



13-2 



121960-001 



gi^NiiE0i>fi@i!e€mr€iii 



ARM, adjusts the RPL field of seLa.tp the ^roarer of its current mlue #iid the value of the RPL field 
inseL/x n 

The CPL of the calling procedure is stored in the RPL field of the return pointer on the stack, as figure 
13-1 illustrates. Assuming the parameter is also on the stack, statements of the form 

MDV AX, STACK_FRAME . RETURN_SEL ^ . ■ ^ - in, 

ARPL STft'eit:rf RftME .f^AR AM_:&E^^^^ - - 

can be used to ensure that the RPL field of the parameter is not less that the calling procedure's CPL. 
When the called procedure uses the parameter, the processor evaluates its right to use the parameter 
as if it had the privilege level of the calling procedure. If the calling procedure passes a parameter that 
it has tio right'tel1i|feJ'to'exceptiion wilt Occiir when the called pru^durfe uses the parameter. 



Every operating system procedure should apply the ARPL instruction to every pointer or selector 
parameter it receives, even if the calling procedure is another operating-^i^t^gj^^i^^^dnre. T^.j^vides 
inexpensive protection against accidental use of invalid parameters. 



Point-of-Entry Scrutiny 



1. to' 



While use of ARPL alone is sufficient to detect such invalid parameters, it has one drawback: it does 
not help to isolate the source of the invalid parameter. An exception will eventually occur when some 
higher-level procedure uses the parameter, but this may not happen until several instructions after the 
procedure was called, and may not happen until after the called procedure passes the parameter to yet 



1. ,'1,2 , jii; zt, fiOL' I 



STACK 



/a-JsnijKV.,.; 



DIRECTION 
OF GROWTH 



SP ■ 



INTERRUPTED 
PROCEDURE'S SS 



INTERRUPTED 
PROCEDURE'S SP 



RETURN IP 
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another procedure. To detect parameter arrors aitjthe earliest opportunity, the operating system shfiuld 
examine pointer parameters with the VERR, VERW, LAR, and LSL instructions. >-!2 ni 

The strategy for scrutinizing a pointer parameter includes 

• Using ARPL as described previously to ensure that the RPL field of the pointer parameter contains 
the calling procedure's privilege level. 

• Using VERR or VERW to ensure that the indicated g^nej^tis^^q^sible ia^,t]^e c^^ip proceduye's 
privilege level. VERR also determines whether the liidicaled segmeiit'is rea&lt^, an execute-only 
segment, for example, is not readable. VERW also determines whether the s^pEOBnt is writable; 
only a writable data segment passes this test. " ' ' ' ^''i " sn""-. ' -'f neo 

•, Using LAR and LSL to make sure that the offset portion of the pointer parameter actually points 
to a location, within the boundary, pfjtji^ sjegigeptj j^^^^jna^^, ^ indiqate4 
descriptor available, so you can determine whether the segnient is a"ri expandFdown data segment. 
LSL makes the segment-limit field of the descriptor available. If the segment is an expand-down 
' data segment, the offset portion of the pointer parameter must be greater than or equal fe'^tti 

'■''•'segtaeirt limit; trtherwike tie offset must be strictly ^^1^^^^^^^ --■'3-'^' 

Refer to the appropriate language reference manual for details concerning the use of these instructions. 

This strategy for parameter validation is somewhat more costly than using the ARPL instruction alone, 
as described in the previous section. Therefore, you may wish to limit use of this strategy to those 
operating system procedures that can be called by less privileged, applications procedures. 

: • .: .;^-i;I;^nK 'i- , '^cijj . i.. ■■. ■j'.-./ii , ...in-' 

USAGE PRIVILEGE LEVEL 

Generally, operating system primitives that act on operating system objects (such as the semaphores 
and mailboxes discussed in Chapter 5) have call gates at PL 3. Without further protection, procedures 
aTaijy privilege level in a task can use those objects for which descriptors id ti5S*"EDTrStRJfi 
freedom violates tilts principle behind privilege levels, however. Consider these tvm cases: 

• A database-management system that runs at PL 2 creates a mailbox for passing recovery informa- 
tion to a separate task that is responsible for writing recovery information to a magnetic tape. A 
task at PL 3 accidently uses the wrong selector in a call to the operating system and sends an 
unrelated message to that mailbox. Later, when using the audit tape to reconstuct the database, the 

> database system reads the strange record and fails. | 

• Procedures of the same database system use a shared data segment so that they can access common 
database parameters regardless of what task they run in. To synchronize their access to the common 
data, they define and use a semaphore. A less privileged task uses a wrong selector in a call to the 
operating system and signals this semaphore prematurely, permitting the shared data to be incor- 

j rectly changed. The database system fails when it next trijes to use the incof (tela. 

These examples illustrate the need for additional- pi^itec^on over the use of operatiHf««ystem objects, 
!such as semaphores and mailboxes. 

i . - - i 

By associating a usage privilege level (UPL) with objects, the operating system can provide protection 
analogous to that provided by hardware for access to segments. By means of a privilege-level parameter 
to the creation procedure, the task that creates an object defines the maximum (numerical) privilege 
level that can use the object. The UPL can be stored either in the data structures that define the object 
or (if indirect naming is used) with the name of the object. In the procedures that operate on the object, 
the operating system can check whether the calling procedure's privilege level exceeds the UPL of the 
object. The calling procedure's privikgSdrarsialifatdjfy^aiM^i^n the stack, as ligufe 13-1 illustrates. 
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SEND PRIVILEGE LEVEL 

Moving or deleting the descriptor for a segment or the name of an object may have even more drastic 
effects on other tasks than using the code or structures in the segment or object. Consider the effect of 
deleting or mailing away a descriptor for a global data segment (for example, a translation table) 
shared by all tasks in the system. A task that assumes the existence of the global segment will cause 
an exception when it references the deleted descriptor slot. This points out the need for control over 
the right to send or delete a descriptor. 

One way of implementing such control is to associate with each descriptor (including alias descriptors) 
a send privilege level (SPL). Procedures that move or delete descriptors (such as SEND_MESSAGE 
and DELETE^LIAS) interpret the SPL and ensure that the calling procedure cannot delete (send) 
a descriptor from tlie GDT or its LDT unless CPL <= SPL. SPL for segments is an attribute of 
segment descriptors and can be stored in tables parallel to descriptor tables. 

The SPL and UPL for operating system objects may be different. In general, the SPL of all descriptors 
in the GDT should be zero or one, limiting the deletion and movement of GDT descriptors to the most 
privileged levels of the operating system. It is quite reasonable, however, to have GDT-based objects 
with UPL of three, so that they are accessible from any level. 



CONSTRUCTING SHARED OBJECTS 

Since the procedure that builds a GDT-based object, such as a mailbox or semaphore, must have a 
descriptor for the object's data segment, there is a possibility (however slight) that some other task (for 
example, an interrupt task) might mistakenly use a selector for the object under construction in a 
request to the operating system to use a similar object. The results are unpredictable, but probably 
disastrous. There are several possible methods for guarding against such a circumstance: 

• Lock out all other activity for that type of object by using a semaphore or other synchronization 
primitive. 

• For the purposes of construction only, use a reserved descriptor slot that other operating-system 
procedures recognize as invalid. 

• For the purposes of construction only, use an LDT slot of the task that is building the object. 

• Use an invalid type extension code for the object until it is completely built. 
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r.-.'iJESi. 

8254 Programmable Interval Timer: an Intel counter/timer device that provides three independent 
16-bit counters and six counter modes. For operating-system applications the 8254' can proviite tjnie^ 
interrupts for use by the software scheduler. -= 

8259A Progrtunmable Interrupt Controller: an Intel device that handles up to eight vectored priority 
iiC^fsppts f0f The chipris ()c$igne4 to nu^mxe; strftware and reai-time> overhead in liandUiv 
mi^tyfyej priority interrupts. It,]l^$^i«er^l9f||liSSnBi^ectable modes, permitting optimization for a 
variety of system requirements. i 

80286: the CPU chip of the iAPX 286 architecture. 

80287: ^ mitnerics processor teMeosion chip of the iAPX QM/SXy'^pset,^, '^J. . ; 'i r.; .n .«i 

access rights: the attributes of a segment, deHned by a descriptdK =fl(^'^}i^iK^'a se^ift«Sit'"teah'!S 
used by instructions in other segments. 

■■ '..I 

accessed bit: a Boolean in the access rights byte of a descriptor that the processor sets when it loads 
the descriptor into a segment register. 

address mapper: a hardware device that selectively translates the CPU's addressing signals into signals 
of another fom. , . • , » 

aktuK one of several descriptors for a Kgnient/ Mc6 alias Aay deihne''a ^1^^ rights, 
or (in s(m^ c^ses) limit for the segment. 

alias list: a data structure that enables the operating system to find all the aliases for a given segment. 

asywhronous: characterized by unpredictable ori^4^#i@m^S!teaii^d£3^ jar 

baifcttfidBrtHiilaehstenr (field in a'TSS that Mra^es tlietaskrto^ Invtdced when then onntot task 
executes an IRET instruction. The processor reads the back link only if the NT flag is set. The proces- 
sor sets the back link to point to the TSS of the former task when a CALL instruction or interrupt 
ctenra&lHidE^-ramtc^ -'ii': ■ ■ arii oi r.,ro!jqt. xliaiq^. J-=:rfl ■ 

base address: the 24-bit address in physical memory at which a segment starts. 

busy task: mser tlR!9^entiy'dt^&utiiig fa^^or^ir^'bM i bkck-link dl^if'from'tHPeilKiitly execiif^ 
ing task. A busy task has a type code of three in the descriptor for Us TSS. 

"Hi 51 .IJ.'. J . II.-.- I £ 'ic i<::i!!-j<:p-j>. Ufr'i.Ai drfl iv sgn^rfv iT-h ri9^-.'.-r.-t! . .•J' !-■•. ■; fn-j 

binding: the process of translating a symbolic reference to a form that the processor can interpret 
d^ectly. 

see bootstrap loader. .rioiu!.xr.;,; jx^n ^u n.; ' ; j« 
bootstrap loader: a;;SaalI, usi^y,$^M;eei!ii9«lit|w^ian wl^r 

feaftife^49%^t- ^^ca:,. : •:ji'v siisb ^utMLH -At wt ijJi-i-jqo y 7, Mbj ■,•<•; iq isrijons 'ti -i}-;:- r.-, lu' :ot. v.^ n ii 
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boodoadable module: a module coataining ^$$$^^^E|^$tJ0e in a simple fonnat that expedites loading 
by a bootstrap loader. 

boundary tag: a field at the low or high end of a block of memory i^ed by the memory allocation 
algorithm to distinguish between allocated and unallocated blocks. 

breakpoint: a position in a program marked in such a way that intervention can occur when execution 
of the program reaches that position. 

baddy system: a memory-management algorithm that partitioiKi'^n^iflMy Mi i^S^Aaf <hiemory blocks 
of equal size<^iMi%otb'Moeks of ^ pair are not 'tts^, ihef <e0#eMWi^Wii'&larg«f 't>£^ th^t ako 
has a partner or "buddy" of the larger size. : y; 

buffer: an area of RAM used for transferring data to or from an external device. 

built-in: in PL/M-286, a predefined identifier. . ; . ^ ■ -<:!^i:^oci(: • hi h-. i.i • , „ ;i 

Builder, ,see,4^Jf^«tf5jpffJOT ,;d i.^aH-i. .j-, 



BUSY: an input pin to the 80286 used by a processor extension such as the 80287 to indicate when 
the processor extension is unable to accept a new instruction. 

call gate: a gate used to transfer control to a procedure in a segment of the same task at an equal or 
^nunierically) lesser privili^e leyeU ,. ,|,^.: „; .,p; -.. , .< 

carry flag (CF): one of the six arithmetic flags typically used for unsigned integer comparisons and 

extended precision arithmetic. CF is set by a carry into, or a borrow from, the high-order bit of a result 
f^^jaiai;'^ .*nv' ■■: ■• ■■uij L sni!.-* vfiSi zKiic. nac.-i inc.tnj-. :=i.'fs 

code segment: see executable segment. 

combine type: one of the characteristics that the Binder associates with segments. The Binder combines 
segm^lts^onlyrif'tii^ llav«viea|g]^lAbtei@(»lbiAflsi%^ ■jlOKr.ibo 'i u/ /d h-jwi^vj-a..'-- >jioai'r:4Mi\(?Ji 

compaction: relocating allocated memory segments into coos^saUim locations in order to bdng/togetheli 
all unallocated memoiry blocks. ,. .jj^o i .■ : - ., ju;. . : , ■ .tjs/-- 

compiler control statement: source statements that specify opticHis to the compiler.-08ttrob^aitewBi«(s 
begin with a dollar sign ($) in the left margin. 

conforming segment: an executable segment that executes at the CPL of any segment that calls it. A 
cpitf^mii^s^QeQt:isid(^^fiedbyabit intheacc»^ng^jtebytf;,ofi^ : , ; :> • /;•<•■( 

control flow transfer: any change in the normal sequential progress of a program. JMP, CALL, RET, 
IRET, and INT instructions, as well as exceptions and external interrj^ts^j^pan cau^ a.j.cMo&g |g 
control flow. . . . . jr . i 

coroutine: a type of subroutine that cooperates with other coroutines in quasi-parallel execution. A set 

of related coroutines transfer control from one to another. Each coroutine maintains local variables 
across invocations and maintains an independent instruction counter that determines where to begin 
execution upon next invocation. ■^-■■■■■.i. . ■ »n»o6 

criticai section: a procedure or portion of a procedure that-operates on shared data in such a way that 
it may act incorrectly if another procedure operates cm the same data within the same time interval-. ■ 
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CS (code segment) register: the segment register that provides addressability -fort ai^ess-tpiniitA^ 

current privilege level (CPL): the privilege level that the processor is using to execute the currently- 
accessible executable segment. CPL may be equal to DPL of the executable segment, or CPL may be 
numerically greater that DPL if the segment is conforming. 

datase^ent: a se^ent that contains data (otber tlm immediate dat%> lor aa execfn^ble.)s^ment 
A data segment is identified by a specific type code in the descriptor of the segment. ' 

descriptor: an eight-byte item that defines the use of memory in an iAPX 286 protected-mode system. 

descciptor table: one o£ the ^tocessarrrecogiiized tables that contain the descriptors for the system. 

'a««nables)BTe'ttoC3®T;-tfeI©'f5'and'l!,OTfa'^ ■■•r ■ ■ \ '■- ■ ■ ., 

■' ?i I 

descriptor privilege level (DPL): the privilege level defined in the descriptor of a segment. 

device driver: the task or procedures that use knowledge of the physical characteristics of an I/O 
d«*liG»t©«affyc*dt%i8her4evel I/O requests. 

direct I/O: I/O operations in which the CPU participates. 

dispatching: determining which task the processor should work on, and switching the processor to that 
task; also known as "scheduling." 

double fault: a fauh that ocau:s while the processor is attempting to handle a prior fault. 

DS (data segment) register one of three segment registers that provide addressability to data segments. 

dynamic system: an application in which tasks begin and end relatively frequently. 

EM (emnlatiQB BMile) bi6 a Boolean in the MS W that indicates to the proeesiMiF whether ESC instruei- 

tionprocessi«f 'iS%rife^mulfecaiby--soft«aW' '" ' -•»•» -'"'^■" ■■^ '-'v «!'.•-«!' -:1 

emulation: software interpretation of instructions for a processing device (such as the 80287 Numerics 
Processor Extension) that is not(pi«si^elin'tii« ^^KHlLsnj or,,-, ,( kj ii .a i .: n<; 

entry point: an executable-segment offset that identifles the stiMs^ point for executicai, lis^iMlien ttie 
segflieiit 'is invoked^ via a gate«- • • .:. ;i. aiow ^i,, -o.t^ -lo.ti-.. i- . ^ _ :.;./!_-.! Lnt .gsi'l ' 

error code: a word automatically pushed on the stack as a result <rf certa£Eii^id^3n&.^& liffift^ cdfe 
helps identify the segment involved in the exception. 

ERROR: an input pin of the 80286 used by a processor extension (such as the 80287) to signal error 
conditions. 

ES (extra segment) register one of three segment registers that provide addressability to data segments. 
ESC or ESCAPE instruction: an instruction (usually for a processor extension) identified by the five- 

Mt prefix iniill^ IR ;r -'' b.is 3ff;d mi-' -•.,rie'n»;. j.R.-ii xV-l'V ^i,-; '! . ■ -jv; n JO 

P£^(external) bit: a Boolean initheubrroTi^^ds whicllj:iii^en f^'iiidteictes S^ti^«i^0eiKliiua% 
factors outside the control of the task in wtaiebcftftxiGepp^ii fixmsu viv.. a yivdJ - i?' ■>!',: u fsj 
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exceirtioiR- a pitK;essor^leted»(i condttion' thai -requires sofitwareiin^veAtic^^ 
nicates exceptions to software by means of tlie interrupt mechanism. 

executable segment: a segment that contains processor instructions. An executable segment is identi- 
fied by a specific type code in its descriptor. 

execute-only dement: a special case <rf an executable segment that the processor can access for the 
purpose of fetching instructions but :cannot access for the purposes of reading data. An execute-only 
segment is identified by a Boolean in the access-rights byte of its descriptor. 

expand-down segment: a data segment that contains a data structure (such as a stack) that grows 
toward lower memory locations. An expand-down segment is identified by a Boolean in the ^jocessp 
rights byte of its descriptor. Offset addresses in an expand-d6!m>S(^o£0Je9(fen9CKAn die>valBfi«ontamed 
in the limit field of the descriptor thru OFFFFH. 

exportation: a process by which a system-software interface is made available to applications and other 
system programs. Gates and segments providing access to system services (such as operating-system 
primitives) are placed, via the Builder's export definition, into a linkaMOvMoM^t This ^odule i^-MsM 
when building loadable tasks that depend on the exported services. 

EXPORTS list: a clause of PL/M-286's extended segmentation control syntax that specifies the public 
identifiers that may be referenced from outside a subsystem. 

external reference: a reference to an identifier that is defined as PUBLIC in another module, 
fault: an interrupt that results from an exception. 

fetch policy: the algorithm that determines which segment to bring into RAM from secondary storage 
and when to bring it in. 

Gist lit aJig«rii9iin; ia dyiuH]M« ^&KagpiAUs^ytMQ:algori.thm t)»l> sati^fi^s a refluest for spaoi/.with th<? 
first unallocat^ block of storage whose size is greater thftft/Sfs equail to tber requested size. 

flag: one of several Booleans maintained by the CPU, including the arithmetic flags (CF, PF, AF, ZF, 
SF, OF>, the ©wtrol flags (TF, IF, DF), and th.em^W^i^mdl^)><>n ri ii^ri' - -i t,. sooiI 

flag word: a 16-bit register of the 80286 that contains the arithmetic flags, the control flags, the nested 
task flag, and the lOPL. The processor saves the flag word in the TSS with,^ch task switch and lo^ds 
the flag word from the TSS of the next task, thereby enabling each task to use the flags without 
WiJsrfereiiceTroigj,0jjipr,t^\^, M-i^ o >: i/.-. , .-. 

fragmentation: a condition resulting from some dynamic storage-allocation algorithms, in which 
unallocated storage is dispersed in many small areas, ■ t j , 

gate: a gate descriptor. 

gate descriptor a descriptor that defines a protected entry point to an executable segment or task. 

GDT register a renter of the 80286 that contains the base address and limit of the ©IIT. ' . : q lid 

global descriptor table (GDT): the descriptor table that cbntains descriptors tltatlcan be iKsed by evifi^ 
task in the system. There is only oneiGDT..|)emMJoee8S0iljiriv» iii a"...} ■; io^.'n . \ , jj-jkI 
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handler table: a table of selectors to call gates that identify the procedures for servicing asynchronous 
events such as interrupts or software signals. A handler table is used by an operating system's^erruiit 

distributor and signalling primitives. 

I bit: a Boolean in the enor code which, when set, indicates that index portion of the error code points 
to an entry in the IDT. 

iAPX 286 Binder: an iAPX 286 program development utility used to link modules, combine segments, 
and create a singl&'task, loadable output module. 

iAPX 286 Systow Bidllen HXt configuration utility for iAPX 286 protected-mode systems. 

IDT register: an 102^)iiie%i;^'<that stores the base address^^|d.lii{u||#.}^PrI^ i^H, ; tq^ 

index: the field of a selector that identifies a slot in a descriptor table. 

indiiifict I/O: a style of I/O interface in which I/O operations are executed by an independent. proce^ 
^i^t by.tll©g^> .M. : ^^( JO * •: ' ■ .-i. ....,;;.r.^ -.. >■ ^^Ki 

■ i< r jS'.; V 'r.oiiv.. .: . " •;. . '.r. sJOv'.'-^i ion ^sm ■■■cSj 
iHtmvpt: 1) the electrical or logical signal that an event has occurred; 2) the mechanism 1^ which a 
computer system res^fb(iuii^f^(t9i^j|te-t^^ , /\{ 

interrupt controller: a device (such as Intel's fSrj^iMwable Interrupt Controller) that assists 

the CPU in responding to multiple external interrupt s^nals by performing $uch functions as detection, 
priority resolution, and identification. 

interrupt descriptor table (IDT): a descriptor table that contains gates to the han^r praeidures or 

ba|^ert^|^,|o|^terrjjjjtsa^d^J^^J^^^y^ 

gates. 

Interrupt distributor: an operating-system interrupt procedure that transfers ddA'l^rol to a task-defined 
pn^edure, for servicipgjjie jaiei;rupt. 

Interrupt-enable flag (IF): a control flag of the 80286 that determines whether the processor responds 
to external interrupt signals presented at the processor's INTR pin. 

Interrupt gate: a gate that identifies the entry point cff a prbcedttre for handling an interrupt. When an 
interrupt transferk control through an interrupt gate; thcf iirtMSe^or resets the interrupt-enable flag. 
Interrupt gates iur« valid only in the IDT. 



interrupt hariB^pj^:^^i^>t^'{{^ ^ '.^..-st- a , 



IniCiitiralpt lateiU^i^^Mie fi^tM^jgie^oiicurreiice of an interrupt signal to tb^ i3i^fttM^#%be fl^ 
instruction of an interrupt handler. . . ... . .. j i i; ■ . ;;n vx -ji'> wL-j-.r-j i 

interrupt procedure: an interrupt handler that is identifled by i^4iii)irlfpii^tl^^ thip gafe.'IQi'intii^ 

rupt procedure runs in the interrupted task. 

interrupt task: an interrupt handler that is identified by a task gate and runs as a-task separate from 
the interrupted tindc. .vsrffoiip sno moii ^jf?BJ t-jn! .■•<} TdJ 9(fT .1 d . srii 

tntlOT'upt vectoring: the mapping from a« imertupt souree to the interrupt handlesiUfl^ttftB iAPX 2S6 
architecture, the 82S9A andtlieiIOTi|»e<i^^podeaMiQf#i«i&9luru|M»v«i^^ ' i u nt^ 
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intersegment reference: a reference to a location in a segment other than the segment containing the 

tattrasepneat reference: a reference to a location in the s^e segment as the s^auM ctmtaining the 

interlevel reference: an inters^m^ reference to a segment that has a different privilege level than 
that of the segment containing- thetiWerence. : . 

intertask transfen a transfer of control flow to a task other that the current task. 

I/O-mapped I/O: a style of I/O interface in which I/O devices respond to addresses in an address 
space that is distinct from the memory address space. Special I/O instructions (IN, INS, OUT, OUTS) 
trigger I/O opontions. The 80286 uses the M/lO pin to distinguish memory addresses from I/O 

addresses. 

I/O privilege level (lOPL): a two-bit item in the flag register of the 80286 that controls the current 
task's right to execute the I/O-related instructions IN, INS, OUT, OUTS, CLI, S'tt?l©eK. A f»0j»- 
dure may not execute any of these imtructions if CPL>IOPL. 

., <j. -ffH ..,„:.■, "ij (i tad tny? «s .'siii !t>»i.j:.' lew^'-l !tont3;-»3 «!• : , ■ .v.'iii 

I/O subsystem: the portiM<(ff^'^i«^'^fi[»»^M»iei^t:#f^>il^!M^^ - ■^"'■^'^ 

IP (instrnction pointer): an 80286 register that contains the offset of the instruction to be executed 
within the current code segment. - 

j!>Sjil:.!.istji hnt, ,, lur,- 
kemek that S(g^m @f an operating system that implements the most pdmitive of its functions. 

WV^n^'an «D286 t^l(^r^Ma^yi[Bi§sSfi^liJ,iki^k L6t. 

limit: the field of a descriptor that defines the offset of the last byte of the segment. 

linkable module: an object module created by iAPX 286 translators, by the Binder, or by the Builder 
that can serve as input to either the Builder or th(^,B^jE|d|^^ ^^l^l^^e iQpdule requir{^^{^^|p^pro^^3|^ 
ing before it can be executed. . ' ^ , ' ;, ' 

linking: the process of combining segments from one or more input modules and resolving references 
between modules. The Binder provides linking services for iAPX 286 program development. 

loadable module: an executable object module (usually created by the Builder or the Binder) that has 
a fOTmat suitable for processing >|r a j^^e^/^i^ systgib:..! .i.i-si 

loader the task or procedures of an opfrating systein that plia|C!{^an<f|^j^. n^^)e.j^^ 

it for execution by the operating system and the proc^sor. . ;,]!>,,£(! jqui r. n i oi 

l«ilA4ii«^:.;alt]g^^liiB)9a;t^|^l^^^ r,, bi^jim^fci n u.. 

local descriptor table (LDT): the descriptor table that ccmtains descriptors that are (generally) private 
to a given task. Each task may have an LDT. ^ ^HjnsMim wUy descriptprs^th^t are in iu LOT or in 
the GDT. The LDT protects tasks from OTO another. ^ -.,(! 

loi^cattHgnuNit: !thex6pres«ail9tion!<4!ft s^oaeiit used by traadaMrs.and program development utiliti^ 
prior to the tiro&N^^0es«^C!i^!ei«i«nif%tpl«Bedr«qf$ybii^^ m . ::rr, 
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machine status word (MSW): an' 80286 register that includes the TS, EM, MB,, and PE Booleans; 
These items are global to the systent and are not a part of the task state. i t j itU 



; mechanism for sending messages between tasks. The mechanism consists of tw<| 
queues: one a ^oene of imdelivered me^geSj tiie other a queue of tasks waiting foe mrasages. Kfessi^iii 
arc delivered in FIFO order. 

memory management: the set of operating system functions that deal with the allocation of RAM to 
taafealiik is xjnurx. -.q 

memory-mapped I/O: a style of I/O interface in which I/O devices respond to specific addresses in 
the memory <addr<as$'^>a«e. I/0<|^^syeas are tri^ered by standaid instructions that read from, and 
write to, memory locations. ' .,u ! ^ 

ttta&iige: a unit of intertask communication. 

'If 3 tCx iji 0S?'.~- ' ; - ! -r ■ ■?. 

module: a compilation unit or a combination of compilation units. 

MP (math present) flag: a Boolean in the MSW that indicates whether^^tib»ioi^iextem{oii'(sucb'^ 
the 80287 Numerics Processor Extension) is present. 

:.i■!•)■!s:^■' i-'-' • ;ltl| 

mutual exclusion: preventing two critical sections from executing concurrently. ^ 

mnhiprocessing: using more than one CPU to execute a multitasking system. 

■nzi'. ■ Efijsrtr e • qiq 

multitasking: the capability to support more than one task either simultaneously (by uslt^'Wi^i* tt^A 
one CPU) or virtually simultaneously (by multiplexing one CPU among several tasks). 

nested task (NT) flag: a Boolean in the flag word that indicates the existence of a back link field in 
the TSS to a previous TSS. i 

non-maskable interrupt (NMI): an external intemipt presented to the NMI pin of the 80286 that tlile 
processor does not ign^e, ev^.when IF is reset. 

not-present segment: a segment whose descriptor has the present bit reset. In a virtual-memory syst^^ 
this condition normally indicates that the segment has been evicted from RAM to make space for oth^ 
l^egments. 

.")r)nj3vo-ip;ii- ■ . SJi'tstfT li-xj-Ji v.ils-iCi A X.J ! jUijbrtf .-.i/.i • ■ 

nucleus: see Kernel. 

nullify: assign a null value to. 



"fnmuat extension (NPX): the 80287 processor which cooperates with. ,the.8Q286, CPU, 
extend its pfocessiag power in mathematical applications. 

object module format (OMF): a standard for the structure of object code files. 

OF (overflow) flag: an arithmetic flag that indicates when a signed operation produces a poeative number 
thafeis toQl8||^ttiKaa>(a^tive;iiiii!^«^ 1^^ r.-.^ 

ofl^set: theadirapldfia loca^dBiwitUn r^gment, expressed as a quantity to be added to the base 
address of the segment. ,J«i;jl --v f jns Lasjsi'/nr; ,.i m sru -y-.^wv i; I. .'■ ,-i jini 
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Mtwurd' Calb the attempt to call a procednre ia another segment whose D% is niuneiiiaMy { 
thanCPL. .iiMf: ■A'::-\ Jib naq a v.hi ait biifi mvSMi on: c.i 'i- ■ '5 ■:. -jii'^;: swrIT 

parallel taUesa: table whose entries have a one-to-one correspondence with the entries of a descriptor 
tajble^ is&d^t^iBHidate adiiitional information with each descriptor. : .. :,>if' 

parallelism: concurrent execution of two or more tasks or devices. 

parameter validation: checking the attributes of parameters passed between procedures at different 
privilege levels to prevent protection violations or to detect exception conditions. 

■:(■• lie 

P£ bife'.a Boolean in the MS.W. .that indicates wheU^er the. S.Q2&6 is funniog iaji^Taddress modeiobdi 
protected, virtual-address mode. ,,-n''--. -.n. ■ ■ o-n v 

Petri net graph: a notation for visualizing Petri nets. Petri nets are a mathematical tool for modeling 
systems, first proposed by Dr. Carl Adam Petri in 1962. 

physical address: a 24-bit address, such as that used as a base address, capable of encompassing the 
ept^re ajjdr^s ?|8u:^f.th^^Q2^^^ % r;„t • h 8ri)lJ»^^^.- - ^U/ 

^ysical segmcMib a segment as viewed by the processor, to be distinguished from "logical segment." 

PID programmable interrupt controller. See interrupt controller. 

pipes: a mechanism for intertask communication used in the UNIX operating system. Each task views 
^^;i^}fj;ication channel as a file and uses READ and WRITE operations to receive and send messages. 

placement policy: the algorithm for determining where in RAM to locate a segment. 

pointer: an item that specifies a memory location. A full or long pointer includes a selector, which 
indirectly chooses a segment base address, and an offset value, which points to a specific address within 
t^t,5^nprt,,^,o^byjiJ^f^,<»)lsl^*^ . . , , 

preemption: a dispatching process in which the operating system switches to another task even thdugtt 
the current task has not requested any function that would cause it to wait. The operating system may 
preempt one task in order to give other tasks a share of CPU attention. 

preflx: one of several instruction codes that modify the function or the environment of the following 
instruction. iAPX 286 prefixes include the LOCK prefix, repeat preOxes, segment-override prefixes, 

and the ESCAPE prefix. "-'^ 

present bit: a Boolean in a segment descriptor that indicates whether the segment is actuallly present 
in RAM. In a virtual-memory system, the segment may have been evicted from RAM to create space 
f^-toother-segnaent " ' .^^ ■ 1 ^. . o ^^.Usmix^ {.•;-^'.n.. = :> -aw 

primitive: one of the operating-system operations made accessible to applications by some explicit 
mechanism. In the iAPX 286 architecture, primitives are typically procedures with call gates in the 
GDT or LDTs. 

privilege: the r^tlB0K)eBii»e^Kite}pdifti^irftemss^<'(» te<^e«^iasfteiit^R>cessoriiidtmctionStriJ 

piMlege levek^ii):3<i oAecMre Qf prayiiege^l9:-the!<ijA[i^''.2g&.arGlHtecture, privilege is me^ured% 
integers in the range 0-3, where is the most privil^ed and 3 the least. ..Bi.Ti , ,? >. • ■,. : bbf. 
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pri,i01g)9driiiBtract|0iK. .an Jn&truction. that caii be executed <anly. by a fiCDcedore/ininnmg a|,f£jiii^p 
level 0. Privileged instructions indude GLTS; HLT;' L©DT', Ll'DT/LL^IWiiLM f-nt 

processor extension: an optional, special-purpose processor (such as the 80287) that runs in parallel 
with the 80286 and extends its processing power. 

pnrfilen a ptoe^ure or task that collects data about segment usage. 

■■ -iae 3tlJ lo! citiii- ^ilC'L-! ■ . ^, > .■.:>, i>r^:.. . ano ;v>laigs-| ir- . ■■■■■ 

addressing and memory proteetfcss. •;jn^{.>.^sK ji-.>eJ«) ^8 ^r!s ac>- ? ^ i id. 

readable segDient: an executable segment that can be read. It is necessary to read from an executable 
sep^nt *^t-?^egRgi$,PQn^^n;^ bs^^<^le§n,^^*^ft^q$^ 
rights byte of its descriptor. 

read-only segment: a data segment tHat cannot t>d written to/A read-only segment is identifled by a 



.^ rights ^mS^M^mmllmxtt^n^ ... ^?r., -.r., sn-.-nr-t.-..., v.! rn^,,,,.;ri05m « .-feo^ 

real-address mode: the mode of operation of the 80286 that provliles greateslt'ccnnpatainlSty'with til 
^1^^^ without protection and virtual memory addressing. . . t'i'v ■ '■ 

red m^pory: the physical memoiiy, as distinguished from virtual memory. 

real-time system: a system tl»t responds to external events in a relktively short time, as <S(»itrasted 
with a batch system. 

region: a mechanism for providing mutual exclusion among critical sections. A region is similar to a 
semaphore that has the additional properties that 1) only the task that acquires a region can release it, 
and 2) a task cannot be suspended while holding a region. 

relocation: changing the physical location of a segment. 

replacement policy: the algorithm that determines when to remove segments froiil RAM'^^' wUfiifi 
segments to remove when space is (or is likely to be) needed for another segment. 

.1. : Ai£.:.i^^>i ,. jj.ji.-..i-£i.iijiu k. fio;jj»jko & .oi\-M\ JT nt ;m9i? • dm 

resolving reference: see binding. 



•'.':jEJn j/r?s:i! to ■ ::A\. 



requested privilege level (RPL): the privilege-level field of a selector. A procedure tiiay' fb'^Ue^'ft 
numerically greater privilege level for use of a segment by placing the desired privilege level in the 
RPL fleld of the selector that identifies that segment. . . . ■ yutt 

nm-tim« the time a task executes. 

scheduler queue segment: a segment that contains one or more of the task queues used by a scheduler. 
Keeping a queue in one segment may reduce the time for searching the queue. ' 

scheduling: see dispatching. 



pmoiais^ aatM tw0,!ygdjK;iofi.scheduUng a; task:.liardware^ (inteixiip^) .scheduled imod&iir 
softwaieisseieduled nsode. , . ildi 
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scheduling state: one of several conditions that affect the way a taslc is teeated by the schedijl^, 4 
task may: be' ready to exe^u^^ek^cuieif^vwaithtg fen- ^3to nou-i ■ . '- '^ /rr'! i->7tii 

secondary storage: a slower, less expensive storage medium than RAM (for example, disk). 

segment: a variable-length area of contiguous memory addresses not exceeding 64K bytes. 

segment register: one of four 80286 registers that hold addressing information for the segments that 
^Mirenfli^iiljib^Ki^ble by a Thd isegment i«#st(iFs ai«€S>(codiB st^ment), DS (data«ega«^^ 
ES (extra segment), and SS (stack segment). ■' ! ' • i ^: ,, 

sdecton ^iimmtidmm^¥4(i»ieii!^ IMa^ri^rluii'dej^ptof^Mbl^o^M 

semaphore: a synchronization mechanism that comnniiu^f^^'olei^i^de^ &kllii'WtweeiHiil^ 
(or more) tasks via a shared memory location. 

priiiil^ tevel (SPL): a iOftWaFe^iinplemaited measure ^ tbe itg^t to send dr delete a segiriraii 

sha^w ^ask: a duplicate task to enable tiie o^^ting system to perfmin^i^ outvmrd call. 

signal: a mechanism for permitting one task to C(naitU&^iiat^1%£'6(iciiih^i;« tb^Mbtibti^'i^ 
that is not waiting for the event to.occur. 

single step: a mode of execution that permits intervention between each instruction; used primarily as 
a debugging aid. , . . 

slot: an entry in a descriptor table. 

SS (stack segment) register: the segment register that provides addressability to the current stack 
segment. 

Stack segmeiit: a segment used by the processor to hold return addresses, dynamic data, temporary 
data, and parameters. For greatest protection, each privilege level of a task may have its own stack. 
Stack segments usually expand downward. ;. •• i j s > ' 

static system: an application in which the mix of tasks does not change over time. 

subsystem: in PL/M-286, a collection of tightly-coupled, logically-related modules that obey the same 
model of segmentation. 

swap space: the secondary storage area used to contain segments that have been removed from RAM. 

swapping: in a virtual-memory system, the process of moving segments between RA\j[ an4 secondary 
storage. 

swapping managen a procedure or task responsible for swapping, 
synchronization: imposition of an order on the occurrence of certain events, 
system segment: a segment containing a descriptor table or task state. 

table indicator (Iiy. a Boolean in a selector that identifies the descriptor table to whieh .t||eisetei^;fflr 
refers. .t ■ .,\\-)l^u\ j ■ 'iU)i 
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task: a single thread of execution that has an associated processor state. 

task database the collection of infonnation about a task that the operating system needs to store. 

task information block: a se^eMi(M^faHilb»te«i^lwMiW^%>^^e<i^^ <ts6tiMa all<^ 

part of a task database. 

task gate: a gate that identifies a TSS. A control transfer through a task gate causes a task switch. 

tad( KgistM: an 80286 register that points to the TSS of the currently active task. 

.■-\i'jm r.f frt^t-iifi •■ • •• ■)'.«•••. • ••• . 

task state segment (TSS): a segment used by the processor to store the contents of the task-variable 
registers, the stack-segment selectors and pointers for the three most privileged levels, the selector for 
the task's local d^litiCft- tal^/l^l'i^^'t^ii'mjt^ P^'l^ ^if^iTd&k'iH a chain of iiest^ 
task invocations. 

TP (single step flag): a Boolean in the flag word that, when set, indicates that the jprpce^r .^ouJ^ 
cause a trap after each instruction. Typically, TF is used to facilitate debugging. 

thrashing: in a virtual memory system, a condition in which excessive swapping seriously degrades 
paf<Hinance of all ti^ks. 

time-«taaring Systran a multi-user, multitasking system in which processors are multiplexed among 
users. 

ttae slice: the time interval for which the CPU is allocated to a task. 

tnuisiaton an as^mbler or compiler. 

trap: an interrupt due to an exception condition. 

trap gate: a gate that identifies the procedure to handle a trap. An interrupt through a trap gate differs 
from an interrupt through an interrupt gate in that, with a trap gate, intemipts are not disabled upon 
entry into the procedure. Trap gates are valid only in the IDT. 

Trojan horse: a type of protection violation in which a procedure passes a selector that it has no right 
to use to a more privileged procedure that does have the right to use it. 

trusted instruction: one of a set of I/O-related instructions that cannot be executed unless CPL is less 
ttem or equal to lOPL. The trusted instructions are CLI, STI, IN. INS, OUT, OUTS, and LOCK. 

type code: a value bi a descriptor that specifies the intended use of a segment. The processor laterprets 
the type code to ensure that segments are used only as intended. 

type extension code: a software extension to the Qrpe code concept that includes usages recogmzed by 

the operating system. 

UDI (Universal Development Interface): an Intel standard for interfaces to operating-system services. 
■M^ privilege level (UPL): a software-defined measure of the right to use an ^erating-system object 
vectoring: see interrupt vectoHi^. 
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virtual address: an address that consists of a selector and an offset value. The selector chooses a 
descriptor for a segment; the offset provides an index into the selected segment. 

virtual address space: The set of all possible virtual addre^es that a task can access, as defined by the 
QDX wtil'th« tasiifs U)TnlI1te>pftltewli.lP«i^3^^ is one gigabyte. 

virtual memory: a style of memory management that permits the virtual address space to exceed the 
physical address space of RAM. With the help of processor features, the operating system simi^Iate^ 
the virtual address space by using secondary storage to hold the overflow from RAM. 

word count: a field of a gate descriptor that specifies the number of words of parameters to be copied 
from the calling procedure's stack to the stack of the called procedure. 

writable segment: &diUi.s^^t^^(^l^y^^^^;,^i^^ 
in Its descriptor. 

XOS (Elxample Operating System): an imaginary operating system, portions of which are used in this 
K<6F4s'eXk«ii)les. ' 



noqi. by! 'ij.^ ton -rt, .-j iTisJni 



■ 'C-.i \:;'L. .'-'l- iO . JO y\l ,\T^^ i.J ., Mfi iwit:,(meni L-ij.w sfiT ..I'K); itijp:- cfirft 



X 30141 



INDEX 



8089 I /O processor, 8-1 
8254 Programmable Interval Timer (PIT), 4-5, 
4-9,4-13 'biuii 
8259 A Programmable Interrupt Controller^ 

(PIC), 4-6, 6-1, 6-6, 7-6 
80287 Numerics Processor Extension (NPX), 
' 1 - 1 1-7, 7^4, '7'5i M, Chapt^l®*"^ 

access rights (field of descriptor), 2-21, 2-22, ' 

9-2, 11-5, 11-10, 13-1, 13-2, 13-4 
accessed bit, 2-7, 5-5, 9-1, 9-4 9-5, 9-7, 10-2 
ADC, 7-8 - ■ ' ' 

addressing mechanism, ^-1 ' ' ' ^ -•"• v- >; 
ADJUSTSRPL, 2-16, 13-2 
alias, 2-17 thru 2-22, 3-2, 4-10, 4-12, Chapter 5, 

6- 5, 8-2, 9-3, 9-7, 10-3, 1 1-2, 1 1-9, 13-5 
ARPL, 2-16, 13-2 thru 13-4 

ASM286, 3-6, 4-13, 11-4, 13-2 
ASSUME, 11-4 : ' ' 
asynchronous execution, 1-6 

back link (of TSS), 4-1 thru 4-4, 4-7, 4-13, 7-5, 

7- 6, 10-2, 11-10 

base address, 2-4. 2-15, 4-1. 5-3, 9-3, 9-5, 10-3, 

11-3, 11-10. 11-11 
binding, 1-8, 2-8, 2-9, Chapter 11 
Binder, see iAPX 286 Binder ' 
bootloadable, see module, bootloadable , 
BOUND, 7-4 . 
bound check exception, 7-4 
boundary tags, 3-2, 3-5, 3-6, 9-3 
breakpoint, 2-17, 7-3 

buffer, 2-18, 3-1, 3-10, 5-10, 8-1, 8-3, 8-5. 8-7, 
9-2, 9-4 

Builder, see iAPX 28^ ^ystM*BuMpr 
BUSY/ pin. 12-2, 12-3 ' 
busy task. 4-3. 4-4. 7-7 

CALL, 2-7, 2-9, 2-10, 4-2 thru 4-4, 4-13, 4-17, 

6-1, 6-2. 6-4, 6-6, 7-5 thru 7-7. 1 1-3: - 
carry flag (GF),'t-# . I ! ' ! .-.ni.lrj- • 
CLI, 4-6, 4-7, 5-6. 6-2, 8^2 WLi . ' ' ' 
CLTS, 12-2, 12-4 ' ■- - ■ 

CMPS, 7-7 
combine type, 1 1-4 
COMPACT, 11-4,. 11-5 
compaction, 3-10 
compiler control statements, 11-4 
conforming segment, 2-5, 6-2* 6-7, 6-8 
critical sect!0n.5-S!ttirti 5-'?|lS4' / ■ " 



n:CS. register, 4-4, 6-9, 7-5 thru 7-7. 9-1,3^, 9r7. 

0ilWr'll,-3i;llr9. 12-5 MJ. tU 

cunuM jmniBgfi level (CPL), 2-1 1, 2-16, 4-6, 
5-6, 6-2, 6-7, 6-8, 8-2, 10-1, 10-2, 13-3 

.5 

deadlock, 5-7, 5-10 

debugger, akK7»f4„lMqll-10 v, 
deletion 

of segment, 2-20, 5-2, 5-3, 8-3, 9-5, 13-1 
of descriptor, 13-5 
DESCRPsectiBa,ilI-ll,tM<'i2r« ' ■ 
descriptor, 2-2, 2-12, n-6, 11-9 
data segment, 2-2, 2-3, 2-6, 2-14, 2-15, 2-18, 

7-7, 9-3 thru 9-5, 9-7 
dynamic creation, 3-1, 3-2 
executable segment, 2-2, 2-4, 2-6, 2-7, 2-14, 

2-15, 2-17, 6-7, 7-7, 9-7 
gate, 2-2, 2-7 thru 2-11, 2-15, ,6r2. 746^ 9-13 

9-2, 10-2, 11-3, 11-9 
system segment, 2-2, 2-5 
descriptor privilege level (DPL), 2-3, 2-6, 2-9, 
2-11, 2-15, 2-20, 2-21, 4-3, 5-7, 6-7, 6-8, 8-2. 

8- 5, 8-7 

descriptor table, 2-2, 2-12,2-15 ' ' ^ 

see also global descriptor table, local 
descriptor table, interrupt descriptor table 

DESNAM section, 11-11 

device drivers, 5-17, 8-1, 8-2, 8-4, 8-7, 9-2, 9-4, 

11- 2, 11-4 o-^ ■r- 
DI register, 7-7 

DISABLE, 6-2, 6-4, 7-1 

dispatching, 4-9, 4-13, 5-7, 9-5, 11-4 • ' ' 

divide error exception, 6-7, 7-3 

double fault, 7-5, 9-2, 9-4 

DPL, see descriptor privilege level 

DS register, 2-17, 2-18, 2-21, 4-,l2. 7-5; thnit-^. 

9- 1,9-6,9-7,10-1 

dynamic system, 1-7 thru 1-10, 2-2, 2-3, 2-12, 
2-18 thru 2-20, 2-22, 3-1., 4-4, 5-7, 6-5, 11-8 

effective privilege level, 2-16 

EM (eihulatioh mode) flag, 7-4, 7-8, 12-1 thru 

12- 3 



emulation, 7-8, 12-1, 12-4 
ENABLE, 6-2 
ENTER, 7-6 
ENTRY, 11-6 
EPROM, 10-3 

ERROR/ pin, 7-8, 12-1 thru 12-3, 12-5 



121980401 



INDEX 



ES register, 2-17, 2-18, 2-21, 2-22, 4-12, 7-5 

thru 7-7, 9-1, 9-6, 9-7, 10-1 
ESCAPE instructions, 7-4, 12-1 thru 12-5 
EX (external) bit, 7-2 
, \ej£amples, 2-20 thru 2-26, 3-1 thru 3-9, 3-15' thru 
3-21, 4-15, 5-8, 5-9, 5-13 thru 5-16. 10-3 
. thru 10-15, 1 1-6 thru 11-8, 11-12 tlm •> ■ 
11-28 

exception, 1-7, 2-8, 2-10, 2-17, 4-3, 4-7, 5-5, 6-2, 
6-4, 6-9, Chapter 7, 9-1, 11-3, 13-3, 13-5 
handler, 6-7;CMpter 1^9^^^, 11-3, 12-4, 
12-5 

recovery. Chapter 7, 12-3 thru 12-5 
EXECUTE, 11-9 ■ . 

execute-only segment, 7-7, 1 3^ " iW i^-iij 
expand-down segment, 2-5, 11-11, 13-4 so 
expansion direction, 2-5, 5-3 
EXPORT, 11-6 

export module, 11-6, 11-12, 11-13 

exports list, 11-4, 11-5 

extended segmentation controls, 1 1-4 



FAR, 11-4 

fault, see exception 

FINIT, 12-5 

"first fit" algorithm, 3-1, 3-2 

flag word, 4-2 thru 4-4, 6-2, 6-4, 8-1, 8-2, 10-1 

FNINIT, 12-2, 12-5 

FORK, 11-9 i, 

fragmentation, 3-1, 3-1, 9-^ 

FRSTOR, 12-4 , : ,i^i.,asi T i 

FSAVE, 12-4, 12-5 i t..A -i 'fiAgfn 

FSETPM, !l2-2, 12-5 



gate, 2-8, 2-11, 11-6 
call, 2-8, 2-10, 2-12, 2-14, 2-15, 2-21, 3-9, 
4-13, 5-7, 5-12, 6-1, 6-2, 8-7, 11-3, 11-12, 
11-14 . 
interrupt, 2-8, 2-i%;S-2, 6^ 
name, 11-6 - . i . . . 

, tsisk, 2-8, 2-14, 2-15, 4-3, 4-t '6-2, 6-4,-7-5, 
" 10-3 
trap, 2-8, 2-15, 6-2,^6-4, 6-7 
see also descriptoTr £ate 
GATE, 11-6 

GDT, see global descriptor table 
GDT register, 2-15, 10-2 ■. 
general protection exception, 7-7, 8-2 •• -40-4 
GETSACCESSSRIGHTS, 13-2 , X," 
GET$SEGMENT$L1MIT, 3-6, l3-2 ;r;:^| ' 



global descriptor table (GDT), 1-3, 2-12, 2-14 
thru 2-19, 2-22, 3-3, 3-4, 3-7, 3-8, 4-1, 4-3, 
4-10 thru 4-12, 5-1, 5-7, 5-10, 6-7, 7-2, 8-7, 

10- 2, 10-3, 11-2, 11-4, 11-5, 11-9 thru 11-12, 
13.5 . .'..^^.r ■ ■ • .. . 

handler table, 6-7 ■ 
hashing algorithm, 5-3"! m-^i. A??'"'- 

I bit (of error code), 7t2 

iAPX 286 Bin^l«;ijDt.J[l.3- )il-5,«-6. il-10, 

11- 11 

iAPX 286 System Builder, 1-8 thru 1-11, 2-2, 
2-4, 2-12, 2-18, 3-1* 3-6, 8-2, 10-3, 11-3 thru 
11-6, 11-8, lUl!p,ft.Hl ' ^' M - .■: 

iAPX 386, 2-3 - C ' 

identifier, 5-7, 5-10, 8-7 ir 
see also interrupt i()entifier 

IDT, see interrupt descriptor table 

IDT register, 2-15, 6-2 

IF (interrupt-enable) flag, 4-6, 5-6, 6-2, 6-4 

index field (of selector), 2-16, 2-17, 5-3, 7-2 

INIT$REAL$MATH$UNIT, 12-2 

initialization - 1 • jft'^ 

of 80287, 12-2 
see also system initialization 

input/output (I/O), 1-4 thru 1-7, 2-18. 4-5, 4-*7; 

4- 10, 5-10, Chapter 8, 9-2, 9-4, 9-8, 11-2, 
11-4, 11-9 ■ •; ', 

indirect, 8-3 ' ' " ' 

memory-inappcdv8-2 ^ ' : 

IN, 8-1 ■ r V 

INS, 7-7, 8-1 

INT, 2-7, 2-10, 2-15, 4-3, 6-1, 6-2, 7-3 
INTA cycles, 2-15 
INTO, 6-1,6-2, 7-3 
INTRpin, 6-1,6-2, 6-6 

interrupt, 1-4, 1-7, 2-10, 2-15, 2-21, 4-3, 5-4 thru 

5- 6, Chapter 6, 7-1, 7-6, 7-7, 8-4, 10-1, 10-2 
distribution, »-7'tttftl'6-^;. 

flag, see IF 

identifier, 2-15, 6-1, 6-2 
handler, 2-15, 2-18, 4-6 
latency, see intercl^ <e?ponse tilnff ' ! .' . ' j 
mask, .4-7., 1C2-4. " 
procedure, 4-4, 4-7, 4-1 1, 4-13, 6-2, 6-4 thru 

6-7, 7-1, 12-4 
response time, 4-3, 5-5, 6-5, 1 2-4 
scheduled task, see scheduling 
software, 6-1 

task, 4-4, 4-7, 6-2, 6-4 to 6-6, 7-1, 7-6, 9^4, 
12-4, 13-5 

interrupt descriptor table (IDT), 2-12, 2-15, 
2-16, 2-1 8,„ 4-3. 4r5, 4r7, &2,^-4^6t5, 6n7,r; . 
7-2,7-5, 1©4j10.2,i1WI-; fiotJoo, ri.ur-.j 
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"invalid TSS" exception, 7-5 thru 7-7, 9-2, 9-5 
lOPL (I/O privilege level), 4-6, 5-6, 8-1, 8-2, 

8- 5 

IP register, 4-4, 6-9, 7-1, 7-3, 7-5, 7-7, 10-1, 

11-9, 12-4, 12-5 
IRET, 2-7, 2-10, 4-3, 4-4, 4-13, 6r4, 6-6, 6-7, 6-9, 

7-3, 7-5. 7-7, 8-2, 12-5 ; vA .w.- v;'v. 

JMP, 2-5, 2-7,3-9.:2-Mt, 4-3,i^^XKi«!l.i 

10- 1, lQr3 . r-c .1-., 1. . 

LABEL, 11-4 
LAR, 9-7, 13-2, 13-4 
LARGE, 1 1-4 

LDT, see local descriptor table 

LDT register, 2-14, 4-3, 7-6, 9-1 

LDT selector (of.TSS), 4-1, 4-3*J«9..7-5. 10-2. 

.11-11 I • ' -r t 

LEAVE. 7-6 . ! ' - 

LGDT,2-15 i-i 
LIDT, 2-15, 6-2 .n.£ ,. 

limit field (of descriptor), 2-4^1^2-12, 2-15, 
' - ! !2-16, 4-1, 5-3, 7-5 thru 7-7, 9-5, 10-1. 10-3, 

11- 11,12-4,13-2,13-4 
linfcage. 1-10, 7-6 

LLDT, 2-14, 7-6 ; , h , 

LMSW, 10*1 , 12-1 . v/nbsd. 

lq«4iiig» pfogrw loading ; ni.rl? 

loc^l descriptor taWe ttDT), 2-5, 2-12. 2-14, 
2-16, 2-18 thru 2-20, 3-1, 4-10, 5-1 thru 5-3, 
5-10, 5-17, 6-7, 7-2, 8-7, 9-3, 9-4. 9-7, 10-2, 
10-3, 11-2, 11-4, 11-5, 11-8 thru 11-12 
not present, 9-1, 9-2 

LOCAL$TABLiii%l!# , -r 

LOCK, 8-2 

LODTXT section, 1 1-1 1, 1 1-12 

logical segipent, 1-1, 11-2 thru.ll-S. ; ,r : • 

LSL, 9-7, 13-2, 13-4 : > f . ! > 

LTR,4-1,9^1 

MACHINESSTATUS, 12-1 

mailbox, 5-10 thru 5-12, 5-16, 5-17, 8-7, 9-3, 

9- 5, 11-2, 13-1, 13-4, 13-5 
mechanisms, see policies and mechanisms 
memory management 

real, 1-8, 1-9, 2-22, Chapter 3, 5-4, 5-12, 5-17, 
8-3,8-5,11-6 

virtual, 1-8, 2-2, 2-3, 2-7, 7-6, Chapter 9^ 1 1-9 
message, 2-19, 3-9,t4^;:5-4, $-lO, 5-12, 5-16 
module, 1 1-1 thru 11-6 

bootloadable, 11-6, 11-10 

linkable, 11-6, 11-10 

loadable, 1-10, 11-10, 11-11, 11-14 

object, 1-8, 1-9, 11-9, 11-1«* S-h.t-* J? 12 



MQY,7'«6 V .(.- 1' ^ ,f : lid (nv-i-q 
MOVS, 7-7 - 
MP (math present) flag, 7-4, 12-1 thru 12-4 
MSW (machine status word), 7-4, 7-8, 10-1, 

12- 1,12-2 ijvs; A tq 
multiprocessor systems, 3-10 

mutual exclusion, 5-5, 5-6 

naming, ll-l ttetf ll-i6f 11**!,) 1M2„J3-Ii 13-2, 

13- 4,13-5 t-i) /-i - 4<I 
NEAR, 11-4 . - - = -..0 --f 
NMI (non-maskable interrupt), 6-1, 6-2, 10-2 1" 
NOT PRESENT statement, 11-12 

"not present" exception, 7-5 thru 7-7, 9-1, 9-3 

thru 9-8, 11-3 

see also present bit 
NT (nested Usk) flag. 4-2 thru 44^7,.7h6^-4 

11-10 I l isiqari ) 

Numerics Processor ExtetiidoH (ISIi'l^ii^x : 
' 5ce 80287 f,>-.-V ir^v b- icj 

OBJECT, 11-6 i 

object module f<»oiat COMF)^ 11-8, 1 1-10, 

11-11 T-V - 

OF (overflow), flaiS f7T#-{ :■; 
OUT, 8-2 o • .. s 

OUTS, 7-7, 8-2 ' ■ : / i: ' .IS 

outward call, 6-8 

overflow exception, 7-3 ' "1 >v 

•n 

paged architecture, 9-6 

parallel table, 5-3, 13-1 

parallelism, 1-4, 8-4, 8-7 

PE (protection enable) flag, 10-1 

Petri net graph, 8-4, 8-5 

physical address, 1-8, 1-9, 2-4, 3-2 thru 3-4, 

11-10 - .sr ii.:>i -i;:, 

physi«»j «gffleflt, M, 1-2, )^12i 2«lS,''W*l thro T 

11-3 

PIC, see 8259A Programmable Interrupt 

Controller, i- . < iq>- . 
pipes, 5-17 

PL/M-286, 2-14 thru 2-16, 2-21, 2-22, 3-3, 3-6. - 
4-1, 4-3, 4-13, 6-2, 1 1-4, 1 1-6, 12-2, 12-4, 
13-2 

pointer parameters, ie« seleclpt paraiBSters n .n 
policies and mechanismiS '; r. L;. .; - .1 • ' jii 

scheduling, 4-9, 4-10 

virtual memory management, 9-1, 9-6 
POP, 7-6 
POP A, 7-7 
POPF, 8-2 

preemption, 4-5, 4-7, 4-9, 4-10, 4-13 

prefix, 7-1 l3/9l s^siivhf: L. . ,;,>^ ■ i-lS 
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subsystem, 1 1-4 

swapping, 5-12, 8-3, 9-2 thru 9-4, 9-8 
synchronization, 2-22, 3-8, 3-9, Chapter 5, 8-4, 

8-6, 12-2, 13-4, 13-5 
system initialization, 6-S, 6-6, Cbapter 10 

TABLE, n-6 

table indicator (TI), 2-16, 2-lf» f-2 
task, 1-1 

creation, 2-2, 2-18, 3-1, 5-12, 6-9, 1 1-9 
database (TDB), 4-11, 5-12, 9-4, 11-9, 11-10, 

12-3, 12-4 
management. Chapter 4 
state, 4-1, 10-2, 12-3 

switching, 2-14, 4-1. 4-3, 4-4, 4-9, 5-6, 6-2, 7-5 
thru 7-7, 8-2, 9-4, 9-5, 10-2, 11-9, 12-2 thru 
12-4 
TASK, 11-6 

task register (TR), 4-1, 4-2, 4-4, 9-1, 10-2 
task state segment (TSS), 2-5, 2-14, 2-18, 3-1, 
4-1 thru 4-4, 4-10 thru 4-13, 5-1, 6-2, 6-4, 
6-9, 7-1, 7-5, 7-7, 8-2, 9-1, 9-4 thru 9-7, 

10- 2, 10-3, 10-5, 11-6, 11^ thru 11-12, 

11- 14 

TASKSR^ISnTER, 4-1 
TDB, see task database 
termination (of task), 6-9, 7-1, 7-5, 12-5 
TF, see single-step flag 



thrashing, 9-8 

TI, see table indicator 

time slice, 4-5, 4-9 thru 4-1 1 

timer, see 8254 Programmable Interval Timer 

TS (task switched) flag, 7-4, 12-1 thru 12-4 

TSS, see task state segment 

type 

field of descriptor, 2-5, 2-17, 2-18, 2-20, 2-21, 

4-3, 4-4, 6-2, 9-3, 1 1-10, 1 1-14, 13-1 
extended, 13-1, 13-2, 13-5 

UDI (Universal Development Interface), 8-1 
"undefined opcode" exception, 7-4 . 
UNIX, 11-9 

usage privilege level (UPL), 8-7, 13-4, 13-5 

vectoring, 6-1, 6-3, 7-1 

VERR, VERW, 13-2, 13-4 

virtual memory, see memory management, 

virtual 

WAIT, 7-4, 7-8, 12-1 thru 12-5 
WAITSFORSINTERRUPT, 4-3 
word count, 2-8 

writable daU segment, 2-6, 9-5, 1 1-10, 1 1-14, 
13-1, 13-4 

XOS, 11-1, 11-2, 11-4, 11-6 
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present bit, 2-2, 2-3, 2-9, 5-3, 7-5, 7-6, 9-1 thru 
9-5, 11-12 

priimtives, 11-3* 11-4, 11-6, 11-12, 11-14, 13-4 
priority, 2wl 9, 4-6, 4*7, 4-9,"4Bi0;.6-6,^^7' 
privilege level, 1-3, 1-4, 1-8, 2-6, 2-7 thru 2-1 1, 
2-15, 2-18, 2-20, 2-21, 3-8, 3-9, 4-1, 4-2, 4-9, 
4-12, 4-13, 5-2, 5-7, 5-10, 5-12, 6-2, 6-3, 6-5, 

6- 8, 8-2, 8-3, 8-7, 9-3, 9-7, 1 1-2, 1 1-6, 1 1-9, 

■ 1 1-10, 12-2i 1244^ nm 13*2,i 13-4, IS-Smfin 
PROC, 1 1-4 

"processor extension error" exception, 7-8, 1 2-5 
"processor extension not available" exception, 

7- 4, 12-3,12^4 " ■' 
"processor extension segment Bvemia?ic'-'iq 

exception, 7-5, 12-4, 12-5 
profiling, 9-7, 9-8 

jirogram loading, 1-8, 1-10, 2-3, 2-4, 3-1, 6-5, 
Chapter 1 1 
bootstrap, 1-9, 11-10 
protected, virtual-address mode, 10-1, 10-2, 12-2 
protection, 1-3 thru 1-5, 1-9, Chapter 2, 3-1, 3-7, 
4-3, 4^, 4-6, 5-1, 5-4, 5-7, 5-10, 6-j;j-^,aO 
6-5, 6-6, 7-3, 8-1 thru 8»*,'&«7f Cta^SPli^o 
violation, 6-4, 6-9, 7-7 i M i 

PUBLIC, 3-2, 3-6, 3-8, 3-9;tlQ|8fil'Mr'll»6' 
PUSH, 7-6 " ' 

PUSHA, 7-7 

.:. . . 

RCL, RCR, 7-8 -■" ..ioij':'<:.>;> foiiwv.', 

readable segment, 2-7 
read-only segment, 7-7 

real address mode, 10-1, 1©*2 , 
real memory management-,%e^ ih^oiyi -ilK^Kn 

management, real '-'i 
recovery, see exceptions - . .-iv 

region, 5-10, 9-4, 9-5 . ■ , . ; .. .i 

REP, REPE, REPNE, 7-7 
requested privilege level (RPE,V^MS^l6,'.7-2,ri 

13-2 thru 13-4 
RESERVE, 3-6, 11-6 ^'i^' 
reserved word (of descriptor), 2-3, 2-22 
RESET, 10-1, 10-3 

RESTORESGLOBALSTABLE, 2-15 ~i * 

RESTORE$INTERRUPT$TABLE, 2-15 
RESTORESREALSSTATUS, 12-4 
return pointer, 6-2, Chapter 7, 12-4, 13-3 
return link, see return pointer 
return address, see return pointer 
relocatioBf-^f k%Me«t|; 2-4f:2*20i>S42i 5-3,5-12, 

8- 3 

RET, 2-7, 2-9, 2-10, 4-3, 11-5 
RETURN, 11-5 .... 
ROM, 10-1 ,0'-^ .V !i ,\ .noiJq.T!53-:q 
RPL, see requested privilege level i-^ xi'isiq 



SAVESGLOBALSTABLE, 2-15 

SAVESINTERRUPTSTABLE, 2-15 - 

SAVE$REAL$STATUS, 12-4 

SBB;7-8 -^ /-T • ■ ■ ■ 'i: 

SCAS,7-7 

' scheduling, 24 9, 4-1 1 , 5-1 2, 9-5 ' * 

hardware, see scheduling, interrupt 
interrupt, 4-6, 4-7, 4-9, 6-1, 6-5, 6-6, 8-7 
queues, 4-12, 4-13, 9-4, 11-10, 11-14 - ' 
software, 4-7, 4-9, 6-1, 6-5, 6-6, 7-6 
state, 4-5 thru 4-7, 4-lD 
SEGMENT, 1 1-4, 11-6 ' 
segment, see logical segment, physical segment 
segment limit, see limit field ■ ' 

segmented architecture, 9-6 ■ 
SEGMENTSREADABLE, 

SEGMENTSWRITABLE, 13-2 
selector, 2-1, 2-2, 2-8, 2-9, 2-15, 2-16, 3-6, 4-1, 
4-3,5-7,7-6,7-7,11-12,13-1 
parameters, 2-16, 13-1 thru 13-4 
null, 2-15, 2-17, 7-7 
SELECTORSOF, 3-6 

tsiiJhaphbre, 5-6, 5-7, 5-10, 5-16, 9-4, 9^5, 11-2, 

12- 4, 13-1, 13-4, 13-5 .i 

send privilege level (SM-), IM . = ^ -j^'^' 
SGDT, 2-15 ' 
shadow task, 6-8, 6-9 

sharing (of segments), 2-14, 2-15, 2-19, 2-20, 
2-22, 4-4, Chapter 5, 8-7i 9^i\^t; \\-4^i 

13- 1, 13-4, 13-5 
shutdown, 7-5, 10-2 

SI r«^ter, !7-7^ : : ^ 
SIDT, 2-15,6-2 ^ 1 

signal, 4-5, 5-7, 5-10, Chapter 6 ' • 'jJ 
single-step flag (TP), 6-2, 7-3 " 
SLOT, 2-14, 9-7 

slot, 2-20, 2-22, 2-26, 5-10, 11-6, 1 1-14, 13-5 

SMALL, 11-4 -i^ -J 

SMSW, 12-1 

SP register, 4-2,4-12, 7-6 

SPL, see send privilege- level 

SS register,"4-2, 4-12, 7-5 thru 7-7, 9-2, 9-6; 

10- 1 

stack, 2-5, 2-8, 3-1, 4-12, 6-2, 6-4, 7-1, 7-2, 7-6, 
7-7, 9-3, 9-4, 9-7, 10-2, 11-6, 11-9 thru 

11- 11,13-4 
initial, 4-2, 4-3, 1 1-6 
overflow, 7-5, 7-7 
exception, 7-5 thru 7-7, 9-2 

static system, 1-7, 1-9, 1-10, 2-3, 2-19, 3-1, 4-4, 
6-4, 11-9 

STI, 4-6, 4-7, 5-6, 6-2, 8-2 ■ - ' Jlosx.ti 
STOS, 7-? ■ - ! . 1 : - i I .i: : i i ■ ( ..>Wj**oI 
STR, 4-1, 4-7, 4-tl-! I ^- M Jsotoo 
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